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. -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core