[OE-core] Regression bug: dbus messagebus user generation is wrong

Richard Purdie richard.purdie at linuxfoundation.org
Thu Dec 22 09:02:29 UTC 2011


On Thu, 2011-12-22 at 09:49 +0100, Bernhard Guillon wrote:
> we switched the way we chown /usr/libexec/dbus-daemon-launch-helper
> with this commit:
> 
> commit 46e6c3fa8034b12d178d605f3f5d7efe69671a13
> Author: Otavio Salvador <otavio at ossystems.com.br>
> Date:   Fri Oct 21 02:49:51 2011 +0000
> 
>      dbus: use useradd class to allow use in read-only filesystems
> 
>      Move creation of required user/groups to useradd class thus allowing
>      use with read-only filesystems and booting the initial boot.
> 
>      Signed-off-by: Otavio Salvador <otavio at ossystems.com.br>
> 
> 
> We changed the owner ship of the user on the device before this commit. 
> Now we change the owner ship on build time which is wrong. If we change 
> the owner ship on buildtime we cannot know the gid of the messagebus 
> group. On my system it is e.g 117 but on my targtet it is 997. There is no 
> standard mapping for gid to names so we need to switch back to change the 
> group on the device.
> 
> I can send a patch which reenables the postinstall owner ship change if 
> you like.

We have code which is designed to deal with this. The do_install,
do_package* and do_rootfs tasks are run under pseudo which maintains a
separate passwd/group file of IDs which are used instead of the system#s
passwd/group files. When we write out the packages, the named owners of
the files should be correct. When we install the packages, rpm/opkg/dpkg
should be looking up the names and resolving them to the correct IDs for
the system in question. We also have code to ensure the correct users
are present on the system before the packages are extracted.

There have been some issues in this area recently but those issues
should be resolved now. I believe the issue is present in the
1.1/edison/2011-1 release but the upcomming point release should fix
those regressions there.

So which code are you seeing this issue from?

Cheers,

Richard







More information about the Openembedded-core mailing list