[OE-core] useradd.bbclass question

[Mark Hatle]

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

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

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.

--Mark

> Cheers,
> Paul
>