dbus build host uid/gid leaking into target home directory

dbus build host uid/gid leaking into target home directory

[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?

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

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

[Gary Thomas]

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?

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

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

[Peter A. Bigot]

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.

Peter

Re: 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@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.

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

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

[Peter A. Bigot]

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

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

[Peter A. Bigot]

On 10/11/2014 12:16 PM, 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

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.

Peter

> 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

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

[Paul Eggleton]

On Sunday 12 October 2014 16:05:41 Peter A. Bigot wrote:
> On 10/11/2014 12:16 PM, Peter A. Bigot wrote:
> > 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
> 
> 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.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

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

[Peter A. Bigot]

On 10/13/2014 04:13 AM, Paul Eggleton wrote:
> On Sunday 12 October 2014 16:05:41 Peter A. Bigot wrote:
>> On 10/11/2014 12:16 PM, Peter A. Bigot wrote:
>>> 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
>> 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.

Possibly in the section on wic or anything that descibes image building, 
since I expect wic doesn't have this issue.  I haven't used kickstart 
for years but really liked the approach when I did, so I'll be switching 
to wic next time I'm actively working OE. Arguably the classic 
tar/cpio/non-fs rootfs images are fragile unless there's a way to unpack 
them onto runtime media that preserves the name/id mappings defined 
within the image itself.

Peter

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

[Paul Barker]

On 13 October 2014 10:13, Paul Eggleton <paul.eggleton@linux.intel.com> wrote:
> 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.

Cheers,

-- 
Paul Barker

Email: paul@paulbarker.me.uk
http://www.paulbarker.me.uk

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

[Burton, Ross]

On 14 October 2014 07:23, Paul Barker <paul@paulbarker.me.uk> wrote:
> 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 part of BSD tar too (well, Darwin).

Ross

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

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 1641 bytes --]

On Tue, Oct 14, 2014 at 07:23:52AM +0100, Paul Barker wrote:
> On 13 October 2014 10:13, Paul Eggleton <paul.eggleton@linux.intel.com> wrote:
> > 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.

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.

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]

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

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 1860 bytes --]

On Tue, Oct 14, 2014 at 11:43:34AM +0200, Martin Jansa wrote:
> On Tue, Oct 14, 2014 at 07:23:52AM +0100, Paul Barker wrote:
> > On 13 October 2014 10:13, Paul Eggleton <paul.eggleton@linux.intel.com> wrote:
> > > 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.
> 
> 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.

More info
http://lists.openembedded.org/pipermail/openembedded-core/2011-December/053866.html

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]