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

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

On 10/11/2014 06:27 PM, Gary Thomas wrote:
> On 2014-10-11 17:14, Peter A. Bigot wrote:
>> On 10/11/2014 04:10 PM, Gary Thomas wrote:
>>> On 2014-10-11 11:16, 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
>>>>
>>>> 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?
>>>
>>> It does not happen in my builds which are more-or-less stock
>>> Poky (I have my own distro and BSP layers).  Must be something
>>> going on in the meta-ti layer?
>>>
>>> Are you using the latest OE-core (or Poky/Yocto) master?
>>
>> Thanks for the sanity check.
>>
>> I'm using master of poky and meta-openembedded, right at the point of 
>> dizzy branch.  The problem is reproduced with a fresh bitbake 
>> core-image-base with these layers:
>>
>> BBLAYERS ?= "\
>>      ${OE_META_SOURCES}/poky/meta \
>>      ${OE_META_SOURCES}/poky/meta-yocto \
>>      ${OE_META_SOURCES}/poky/meta-yocto-bsp \
>>      ${OE_META_SOURCES}/meta-openembedded/meta-filesystems \
>>      ${OE_META_SOURCES}/meta-openembedded/meta-networking \
>>      ${OE_META_SOURCES}/meta-openembedded/meta-oe \
>>      ${OE_META_SOURCES}/meta-openembedded/meta-systemd \
>>      ${OE_META_SOURCES}/meta-openembedded/meta-python \
>>      ${OE_META_SOURCES}/meta-qt3 \
>> "
>>
>> and these customizations options in local.conf:
>>
>> # Default machine
>> MACHINE ?= "beaglebone"
>>
>> # Want to try this distro, but it enables security_flags.inc which
>> # requires recipe changes.
>> #DISTRO = "poky-lsb"
>> # So instead do some of the pieces so we can still use core-image-lsb*
>> DISTRO = "poky"
>> DISTROOVERRIDES = "poky:linuxstdbase"
>> DISTRO_FEATURES_append = " pam largefile"
>>
>> # The future is systemd
>> DISTRO_FEATURES_append = " systemd"
>> VIRTUAL-RUNTIME_init_manager = "systemd"
>> DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
>>
>> I did try commenting out the override for poky:linuxstdbase and it 
>> had no effect.  I'll try trimming out more stuff tomorrow.
>
> The other big item is that I use sysvinit, not systemd.

Nope.  Pulled out everything but DISTRO=poky and MACHINE=beaglebone, and 
bitbake core-image-base produces a nice sysvinit image with:

root@beaglebone:~# grep messag /etc/passwd
messagebus:x:997:996::/var/lib/dbus:/bin/false
root@beaglebone:~# ls -l /var/lib
drwxr-xr-x    2 root     root          4096 Oct 12 04:26 alsa
drwxr-xr-x    2 102      105           4096 Oct 12 04:29 dbus
drwxr-xr-x    2 root     root          4096 Oct 12 03:48 misc
drwxr-xr-x    2 root     root          4096 Jan  1  2000 urandom
drwxr-xr-x    3 root     root          4096 Oct 12 04:29 wdj

Interestingly, if pseudo is built --without-passwd-fallback, which 
prevents it from referencing the build host passwd/group files, dbus 
won't install:

DEBUG: Executing shell function useradd_sysroot
Running groupadd commands...
NOTE: Performing groupadd with [--root 
/prj/oe/omap/build-beaglesysv-master/tmp/sysroots/beaglebone -r netdev] 
and 10 times of retry
groupadd: cannot lock /etc/group; try again later.
WARNING: groupadd command did not succeed. Retrying...
groupadd: cannot lock /etc/group; try again later.
...
ERROR: Tried running groupadd command 10 times without scucess, giving up
WARNING: exit code 1 from a shell command.
ERROR: Function failed: useradd_sysroot (log file is located at 
/prj/oe/omap/build-beaglesysv-master/tmp/work/cortexa8hf-vfp-neon-poky-linux-gnueabi/dbus/1.8.2-r0/temp/log.do_install.2960)

which is probably a clue.  Adding Peter Seebach in hopes something here 
rings a bell.

Peter