Bug 5694

Summary: smart reads the host's /etc/passwd instead of the sysroot when creating a new rootfs
Product: [Build System, Metadata & Runtime] OE-Core Reporter: Saul Wold <sgw>
Component: devtools / tool chainAssignee: Randy Witt <randy.e.witt>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: Medium CC: meta.mr.watcher, meta.watcher, tomw
Version: 1.5   
Target Milestone: 1.8 M3   
Hardware: x86   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: No (bug/feature does not impact docs)
Attachments:
Description Flags
smart failure to access correct /etc/passwd none

Description Saul Wold 2013-12-31 01:55:10 UTC 
We found this problem when a recipe tries to chown files to a user (www-data in this case). On my host system's /etc/passwd and /etc/group did not have a www-data user, I noted in my logs warnings:

warning: user www-data does not exist - using root

But when I checked the tmp/sysroots/qemux86-64/etc/passwd, www-data user existed in that file.

Further investigation via strace, revealed that smart first looks in the newly created rootfs/etc/passwd (which is not installed yet) and then falls back to the host's /etc/passwd, clearly we need to fall back to the sysroot password file, which will have the right collection of users.

This applies to both passwd and group.

Tom Walsh pointed this issue out originally on IRC
Comment 1 Tom Walsh 2013-12-31 12:42:44 UTC 
Created attachment 1702 [details]
smart failure to access correct /etc/passwd
Comment 2 Tom Walsh 2013-12-31 12:44:48 UTC 
This occurs if you fail to add RDEPENDS_${PN} = "base-passwd" to a recipe which then uses chown / install to change user/group ownership.
Comment 3 Randy Witt 2015-01-29 18:35:11 UTC 
This appears to still happen in dizzy-12.0.0. However, in dizzy-12.0.1 it appears to have been fixed.

In dizzy-12.0.1 when using the attached recipe, the "install -o www-data -g www-data -d ${D}/foobar" fails as expected even when using a user that exists on the host.

I believe this was fixed with the series of patches at:
http://lists.openembedded.org/pipermail/openembedded-core/2014-November/099051.html
Comment 4 Randy Witt 2015-02-16 20:30:29 UTC 
As mentioned this is fixed in 1.7.1.