Re: dbus build host uid/gid leaking into target home directory

["Peter A. Bigot" <pab@pabigot.com>]

On 10/11/2014 12:16 PM, Peter A. Bigot wrote:
> Back at 
> http://lists.openembedded.org/pipermail/openembedded-core/2011-December/053836.html 
> it was noted that the dbus home directory /var/lib/dbus on the target 
> was using the build host uid/gid.  Various discussion agreed this 
> shouldn't happen, but there was no resolution in the thread.
>
> I found https://bugzilla.yoctoproject.org/show_bug.cgi?id=1711 which 
> is marked fixed, but on a newly installed system I find:
>
> root@beaglebone:~# ls -l /var/lib
> total 52
> drwxr-xr-x 2 root root 4096 Oct 11  2014 alsa
> drwxr-xr-x 2 root root 4096 Oct 11  2014 arpd
> drwxr-xr-x 2 root root 4096 Oct 11 12:30 connman
> drwxr-xr-x 2  102  105 4096 Oct 11  2014 dbus
>
> where the dbus uid/gid is from my host system as shown by:
>
> root@beaglebone:~# grep dbus /etc/passwd
> messagebus:x:999:998::/var/lib/dbus:/bin/false
> llc[140]$ grep dbus /etc/passwd
> messagebus:x:102:105::/var/run/dbus:/bin/false

Pilot error.  This ultimately turned out to be a side-effect of the way 
I create my image media: I unpacking the rootfs tar file onto a mounted 
sdcard outside the pseudo environment and forgot that tar records 
user/group by name not uid/gid.

Peter

> This arises in an image extending core-image-base building meta-ti's 
> version of beaglebone.  (I'm actually trying to fix the same problem 
> arising in a patch intended to make sure ntp's home directory exists, 
> but the dbus one appears to be the same thing.)
>
> The suggested workaround for opkg of using a pkg_postinst script 
> doesn't work in my case because the rpm post-install script gets run 
> on the build host that's creating rootfs.The ownership is wrong in the 
> generated rootfs tar files whether or not there's a post-install 
> script that tries to change it.
>
> For my ntp patch I verified that removing the package and installing 
> it on the target does work as expected.
>
> Does anybody else see this sort of thing?
>
> If not, where in the image packaging code is the magic that's supposed 
> to help pseudo record who's really supposed to own the files and 
> re-apply that when the image packaging is done?
>
> Peter