dbus build host uid/gid leaking into target home directory

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

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

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