[OE-core] dbus build host uid/gid leaking into target home directory
Peter A. Bigot
pab at pabigot.com
Sun Oct 12 06:31:26 UTC 2014
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 at 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 at 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 at beaglebone:~# grep messag /etc/passwd
messagebus:x:997:996::/var/lib/dbus:/bin/false
root at 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
More information about the Openembedded-core
mailing list