Re: host-user-contaminated QA check

[Seebs <seebs@seebs.net>]

On Thu, 02 Feb 2017 18:17:29 +0100
Patrick Ohly <patrick.ohly@intel.com> wrote:

> On Thu, 2017-02-02 at 11:12 -0600, Seebs wrote:
> > > But I find mapping to root:root more attractive because it makes
> > > packaging simpler (less worries about accidentally copying the
> > > original uid) and the builds faster (no need to run the QA check).

> > Hmm. I think I would rather have the QA check, because if a file's
> > supposed to be non-root, and ends up root instead, that could cause
> > subtle problems, but we'd no longer have a way to *detect* those
> > problems.

> But that's not the kind of the problem detected by the QA check, is
> it?
> 
> It warns when the owner of the file is the same as the user who did
> the build, but because root isn't (normally) used for building, files
> accidentally owned by root on the target won't trigger the warning.

Right. But the purpose of that is to detect files which didn't get
their ownership correctly set. If we change to a default which we can't
detect, then we can't detect "files which were supposed to have an
ownership but didn't get it".

The idea here is that, although there's some performance cost, we
*intend* to require that every file installed have its ownership
determined in some way by the recipe, and if you don't do this but copy
in files you didn't set ownership on somehow, we want to detect that.

("Created under pseudo" is enough to count as "ownership determined by
recipe", it doesn't have to be an explicit chown.)

I think that, if we default to root:root, we'll end up with recipe
errors going unnoticed, when they could have been caught. And if we
default to -3:-3 or something similar, I think we'll catch errors we're
currently missing. For instance, what happens if a recipe copies host
/etc/services in, preserving ownership? Right now, we get a plausible
answer, but that's still actually host contamination!

-s