dbus build host uid/gid leaking into target home directory

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?

Quoted 29 lines · Peter A. Bigot

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?

Quoted 1 line

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?

Quoted 30 lines · Gary Thomas

Quoted 29 lines · Peter A. Bigot

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?

Quoted 8 lines

Quoted 2 lines

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.

Quoted 69 lines · Peter A. Bigot

Quoted 30 lines · Gary Thomas

Quoted 29 lines · Peter A. Bigot

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?

Quoted 8 lines

Quoted 2 lines

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"

Quoted 6 lines

# 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.

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

Quoted 16 lines · Peter A. Bigot

Back at
http://lists.openembedded.org/pipermail/openembedded-core/2011-December/05
3836.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

Quoted 6 lines

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

Pilot error. This ultimately turned out to be a side-effect of the way I create my image media: I unpacking the rootfs tar file onto a mounted sdcard outside the pseudo environment and forgot that tar records user/group by name not uid/gid.

Quoted 23 lines · On Sunday 12 October 2014 16:05:41 Peter A. Bigot wrote:

Quoted 22 lines · Peter A. Bigot

Back at
http://lists.openembedded.org/pipermail/openembedded-core/2011-December/05
3836.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

Quoted 4 lines

Pilot error. This ultimately turned out to be a side-effect of the way I create my image media: I unpacking the rootfs tar file onto a mounted sdcard outside the pseudo environment and forgot that tar records user/group by name not uid/gid.

I used to use this method previously, and I guess it can still work if you're not including certain packages in your image - but I wonder if we should note this potential pitfall somewhere in the documentation. I'm not entirely sure where such a note would go, though.

Quoted 4 lines · On Sunday 12 October 2014 16:05:41 Peter A. Bigot wrote:

Pilot error. This ultimately turned out to be a side-effect of the way I create my image media: I unpacking the rootfs tar file onto a mounted sdcard outside the pseudo environment and forgot that tar records user/group by name not uid/gid.

I used to use this method previously, and I guess it can still work if you're not including certain packages in your image - but I wonder if we should note this potential pitfall somewhere in the documentation. I'm not entirely sure where such a note would go, though.

Looking at 'man tar', there is a '--numeric-owner' option to always use numbers for user/group names. It might just be that we need to recommend using this option when untarring a rootfs onto a mounted volume. This option is present in GNU tar, I'm not sure about other implementations, and I haven't given it a proper test, but it looks like the thing we want.

Quoted 11 lines · Paul Eggleton

Quoted 4 lines · On Sunday 12 October 2014 16:05:41 Peter A. Bigot wrote:

Pilot error. This ultimately turned out to be a side-effect of the way I create my image media: I unpacking the rootfs tar file onto a mounted sdcard outside the pseudo environment and forgot that tar records user/group by name not uid/gid.

I used to use this method previously, and I guess it can still work if you're not including certain packages in your image - but I wonder if we should note this potential pitfall somewhere in the documentation. I'm not entirely sure where such a note would go, though.

It probably does need noting somewhere - I've been doing exactly this for the last year or so and never even thought that I might be risking bad uid/gid values. It makes sense now I think about it but it never crossed my mind.

Looking at 'man tar', there is a '--numeric-owner' option to always use numbers for user/group names. It might just be that we need to recommend using this option when untarring a rootfs onto a mounted volume. This option is present in GNU tar, I'm not sure about other implementations, and I haven't given it a proper test, but it looks like the thing we want.

Quoted 18 lines · Paul Barker

Quoted 11 lines · Paul Eggleton

Quoted 4 lines · On Sunday 12 October 2014 16:05:41 Peter A. Bigot wrote:

Pilot error. This ultimately turned out to be a side-effect of the way I create my image media: I unpacking the rootfs tar file onto a mounted sdcard outside the pseudo environment and forgot that tar records user/group by name not uid/gid.

I used to use this method previously, and I guess it can still work if you're not including certain packages in your image - but I wonder if we should note this potential pitfall somewhere in the documentation. I'm not entirely sure where such a note would go, though.

It probably does need noting somewhere - I've been doing exactly this for the last year or so and never even thought that I might be risking bad uid/gid values. It makes sense now I think about it but it never crossed my mind.

Quoted 6 lines

Looking at 'man tar', there is a '--numeric-owner' option to always use numbers for user/group names. It might just be that we need to recommend using this option when untarring a rootfs onto a mounted volume. This option is present in GNU tar, I'm not sure about other implementations, and I haven't given it a proper test, but it looks like the thing we want.

It's not supported in busybox's tar implementation at least wasn't with default config last time I've checked couple years ago - we're using it since then without any issues.