[OE-core] dbus build host uid/gid leaking into target home directory
Peter A. Bigot
pab at pabigot.com
Sat Oct 11 23:14:52 UTC 2014
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.
Peter
More information about the Openembedded-core
mailing list