[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Python buildd (was Re: let me help you with progressing bikesheds)



On 27.03.2018 09:22, Julien Cristau wrote:
> On 03/22/2018 10:31 PM, Aurelien Jarno wrote:
>> To do more tests I agree that we should deploy it on more buildds. For
>> *this phase*, I believe enabling lingering and deploying it by hand is
>> the best. Is it something acceptable?
>>
> Sounds ok to me, though I'd prefer if the buildd user (as in the user
> the service runs as) didn't have write access to the deployed code or
> configuration.  Maybe that's a later step though.

Does that really matter? If we were to use user sessions it's a little
hard to prevent that. Unless we tighten up the permissions to make all
service directories owned by someone else, which then makes sudo'ing to
that user a little awkward. Plus chown'ing files around. Because
otherwise someone with write access to ~buildd's home can still juggle
around things.

We could run the build as a different user in theory, but that's
somewhat hard with sbuild right now unless we "sudo -u" over when
executing sbuild. And then we need to manage files as a different user
as well.

If the threat model is that the ongoing build tampers with the files,
I'm open to constrain the build environment even further. Unfortunately
while it seems that a newer schroot version (in a branch that did not
receive any updates for years anymore) would support those, that version
has just been removed from experimental.

That all said: I'm happy to brainstorm and to implement proposed
solutions. Right now that seems to require more infrastructural changes
though and I'd rather focus on getting rid of buildd itself first.

Kind regards and thanks
Philipp Kern


Reply to: