[OE-core] dbus build host uid/gid leaking into target home directory

[Gary Thomas]

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.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------