[OE-core] useradd.bbclass question

[Richard Purdie]

On Thu, 2013-05-02 at 09:50 -0500, Mark Hatle wrote:
> On 5/2/13 9:34 AM, Paul Eggleton wrote:
> > On Thursday 02 May 2013 08:35:55 Mark Hatle wrote:
> >> On 5/2/13 2:49 AM, Andreas Müller wrote:
> >>> on one of my build machines useradd.bbclass seem to use the UID/GID of
> >>> build host. On other machines useradd works correct.
> >>>
> >>> I have the follwing in gdm:
> >>>
> >>> <snip>
> >>> do_install_append() {
> >>>
> >>>       ...
> >>>       chown -R gdm:gdm ${D}${localstatedir}/lib/gdm
> >>>       chmod 0750 ${D}${localstatedir}/lib/gdm
> >>>
> >>> }
> >>>
> >>> ...
> >>>
> >>> USERADD_PACKAGES = "${PN}"
> >>> USERADD_PARAM_${PN} = "--system --no-create-home --home
> >>> ${localstatedir}/lib/gdm --user-group gdm"
> >>> <snip/>
> 
> I don't know how ipk and deb handle this.  But with the RPM system it captures 
> the uname/gname (not uid/gid) and uses that when installing the file(s).  This 
> way the USERADD is processed before the install and the right value is used 
> during the install.
> 
> We may have a problem here where we need to also process the useradd -before- 
> the do_install runs so that it's available for pseudo to use for deb/ipk.

No problem, see below.

>   (But 
> if deb/ipk capture uid/gid vs uname/gname..  unless we set a static value we 
> could still have a problem.)
> 
> Does anyone know how ipk/deb handle this?

The same way rpm does. We have a preinst that sets things up before the
files get extracted. The extraction then preserves the users.

> >>>
> >>> In sysroot /etc/group I see
> >>> gdm:x:990:
> >>>
> >>> In sysroot /etc/group I see
> >>> gdm:!:993:990::/var/lib/gdm:
> >>>
> >>> The folder in packet/image has IDs 42:42 which is taken from build host.
> >>
> >> This says that something ran an operation outside of the pseudo environment.
> >>   So it fell back to looking up the uid from the host system.  (The
> >> alternative is the item was installed -before- the /etc/passwd,/etc/group
> >> was written to the disk.
> >
> > Right, do_install will be well before this stuff happens and it is not a
> > fakeroot task anyway. This needs to be moved to a postinstall script (which
> > should be able to run during image creation).
> 
> do_install is a 'fakeroot' task.  But ya, the useradd action doesn't necessarily 
> happen before it.

Yes it does. useradd.bbclass says:

do_install[prefuncs] += "${SYSROOTFUNC}"

and that call sets up the user in advance. pseudo is set to use the
passwd/group files we add the entries to.

So this does all work and is used by dbus.

> We should -not- be using a postinstall action to change user/groups on 
> files/directories.  This breaks the integrity checking that RPM has.  You can 
> (on the target) issue an rpm -V <package> and it will go and verify the 
> installed files (including permissions, user, group) match what the RPM database 
> says.  Making the change in a postinstall will cause a validation failure.

Right.

Cheers,

Richard