All of lore.kernel.org
 help / color / mirror / Atom feed
From: Seebs <seebs@seebs.net>
To: Patrick Ohly <patrick.ohly@intel.com>
Cc: OpenEmbedded <openembedded-core@lists.openembedded.org>
Subject: Re: host-user-contaminated QA check
Date: Thu, 2 Feb 2017 11:12:01 -0600	[thread overview]
Message-ID: <20170202111201.3fcee3fa@seebsdell> (raw)
In-Reply-To: <1486053547.14889.50.camel@intel.com>

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

> On Thu, 2017-02-02 at 10:21 -0600, Seebs wrote:
> > On Thu, 02 Feb 2017 11:38:00 +0100
> > Patrick Ohly <patrick.ohly@intel.com> wrote:
> > 
> > > Why do we make the real user ID on the build system visible at all
> > > when running under pseudo? The uid and user name have no meaning
> > > there, as the user won't exist on the target system. Instead we
> > > could map the owner of all files to root:root by default, i.e. in
> > > those cases where no other ownership is recorded in the pseudo
> > > database.
> > 
> > We could. Honestly, the underlying reason we don't is at least in
> > part that that makes the behavior differ more from the behavior of
> > "sudo"; with sudo, you see actual ownerships. But that's less
> > applicable here.
> > 
> > I would be more inclined to report a Definitely Absolutely Not Okay
> > user ID, like 65533. (65534 and 65535 have both been used as Magic
> > Cookies in the past, I think.)
> 
> I had considered that approach myself, too. It would make the QA check
> reliable and in that sense solve the problem.
> 
> 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.

-s


  reply	other threads:[~2017-02-02 17:12 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-02 10:38 host-user-contaminated QA check Patrick Ohly
2017-02-02 16:21 ` Seebs
2017-02-02 16:39   ` Patrick Ohly
2017-02-02 17:12     ` Seebs [this message]
2017-02-02 17:17       ` Patrick Ohly
2017-02-02 17:52         ` Christopher Larson
2017-02-02 19:11         ` Seebs
2017-02-02 19:43           ` Patrick Ohly
2017-02-02 20:06             ` Seebs
2017-02-02 17:49 ` Enrico Scholz
2017-02-02 19:29   ` Patrick Ohly

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170202111201.3fcee3fa@seebsdell \
    --to=seebs@seebs.net \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=patrick.ohly@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.