From: Patrick Ohly <patrick.ohly@intel.com>
To: Enrico Scholz <enrico.scholz@sigma-chemnitz.de>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: host-user-contaminated QA check
Date: Thu, 02 Feb 2017 20:29:08 +0100 [thread overview]
Message-ID: <1486063748.14889.56.camel@intel.com> (raw)
In-Reply-To: <lyk298eb4q.fsf@ensc-virt.intern.sigma-chemnitz.de>
On Thu, 2017-02-02 at 18:49 +0100, Enrico Scholz wrote:
> Patrick Ohly <patrick.ohly-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> writes:
>
> > Recently the host-user-contaminated QA check triggered for the trousers
> > recipe in meta-security:
> >
> > WARNING: trousers-0.3.14+gitAUTOINC+4b9a70d578-r0 do_package_qa: QA Issue: trousers: /trousers/etc/tcsd.conf is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated]
> >
> > However, that's a false positive in this case. UID 1000 got assigned to
> > the "tss" user in the target sysroot during the build, and tcsd.conf is
> > correctly and intentionally owned by that user because tcsd checks
> > ownership and refuses to start when owned by someone else (including
> > root). It just happened that the UID was the same.
> >
> > This is likely to affect all recipes with files owned by dynamically
> > created users, in particular when the host system assigns UIDs from the
> > same range as the target system (quick poll: who else has 1000 as his
> > UID on his main Linux box? ;-)
>
> Usually, this can not happen. There is reserved a range for dynamically
> created users (standard says 100-499, some distributions use 100-999).
>
> In this case, there is probably some '--system' flag missing when the
> 'tss' user is created (--> packaging bug).
That's a good point. I hadn't considered that.
In that case the QA check has found a real problem, albeit reported it
in a way that it wasn't obvious what was going on - probably the message
should get extended. I therefore retract my earlier proposal.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
prev parent reply other threads:[~2017-02-02 19:29 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
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 [this message]
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=1486063748.14889.56.camel@intel.com \
--to=patrick.ohly@intel.com \
--cc=enrico.scholz@sigma-chemnitz.de \
--cc=openembedded-core@lists.openembedded.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox