[OE-core] host-user-contaminated QA check

[Patrick Ohly]

Hello!

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? ;-)

The current solution is to suppress the QA check for affected recipes.
But I wonder whether we can do better.

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.

The usual reason for host-user-contaminated is when do_install does a
"cp -a". When mapping the real owner to root, that command will end up
doing the right thing: create a file owned by root on the target.

Because the host user cannot leak into the target anymore, the entire QA
check can be disabled.

The only downsides of this approach that I can think of is that it hides
such sloppy use of "cp" where "install" would be better, and it might be
slightly confusing at first when working under devshell.

Any thoughts?

Seebs, I suppose this wouldn't be hard to implement in pseudo, would it?

-- 
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.