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