Re: [PATCH 0/3] pseudo+image.bbclass: changes to avoid host contamination

["Peter A. Bigot" <pab@pabigot.com>]

On 10/13/2014 05:35 PM, Peter Seebach wrote:
> On Mon, 13 Oct 2014 17:29:26 -0500
> "Peter A. Bigot" <pab@pabigot.com> wrote:
>
>> Basically, even if "root" is a special case, taking this path means
>> making assumptions about what the application is doing based on what
>> system/libc functions it invokes.  Too often when somebody assumes a
>> general tool will only be used specific ways, somebody else will prove
>> them wrong.
> True.
>
> For the oe-core case, it seems like it might be reasonable for us to set
> pseudo up to, by default, get configured with preloaded things which match
> the expected configuration of base-passwd. If people then go overriding
> base-passwd in strange ways, they could break that, but we at least know what
> the default configuration would be, and could possibly even make base-passwd
> check whether pseudo's configuration matches its answers, and blow up if
> there's a mismatch there.

I've discovered a few more cases where OE packages get the wrong target 
username/group for files, at least in RPM packages.

First, revisiting the discussion above I've played with using 
--without-passwd-fallback and adding base-passwd as an explicit 
dependency. This won't work: glibc-initial requires base-passwd for 
group name lookups, and base-passwd includes update-passwd as an 
executable which requires glibc.

The options seem to be to split base-passwd into separate recipes for 
the data files and the utility to break the circular dependency, or 
having pseudo synthesize a fallback passwd/group.  Prior to gaining 
experience I didn't like the second choice, but I like the first even 
less.  As long as pseudo emits a note saying what it's doing so we can 
add the DEPENDS=base-passwd where that's not circular (as with tzdata), 
my vote goes toward pseudo synthesis. I'm hoping somebody disagrees and 
comes up with a better, third alternative.

However, I've also discovered another issue, possibly related to: 
http://lists.openembedded.org/pipermail/openembedded-core/2011-December/053866.html

On my development machine my uid:gid are both 1000 and correspond to 
pab:pab.  Using poky master with MACHINE=beaglebone building 
core-image-sato the corresponding user:group is xuser:xuser.

Running the following script:

find tmp/deploy/ -name '*.rpm' \
   | while read f ; do \
     rpm -qlvp ${f} 2>/dev/null \
       | awk '$3~/pab|xuser/ || $4~/pab|xuser/ {print;}' \
       > /tmp/c$$ ; \
     if [ -s /tmp/c$$ ] ; then \
       echo ; \
       echo $f; \
       cat /tmp/c$$ ; \
     fi ; \
   done

I find the following packages include files that are given group or user 
xuser, indicating that the files were installed with user:group set to 
the host value 1000:1000 instead of being remapped to 0:0 by pseudo, but 
when packaging pseudo does "correctly" interpret the uid:gid using the 
target passwd/group files:

tmp/deploy/rpm/cortexa8hf_vfp_neon/attr-ptest-2.4.47-r0.0.cortexa8hf_vfp_neon.rpm
tmp/deploy/rpm/cortexa8hf_vfp_neon/acl-ptest-2.2.52-r0.0.cortexa8hf_vfp_neon.rpm
tmp/deploy/rpm/cortexa8hf_vfp_neon/systemd-216+git0+5d0ae62c66-r0.0.cortexa8hf_vfp_neon.rpm
tmp/deploy/rpm/cortexa8hf_vfp_neon/perl-ptest-5.20.0-r1.0.cortexa8hf_vfp_neon.rpm

For example:

llc[11]$ rpm -qlvp 
tmp/deploy/rpm/cortexa8hf_vfp_neon/perl-ptest-5.20.0-r1.0.cortexa8hf_vfp_neon.rpm
-r--r--r--    1 xuser   xuser                   45590 May 26 08:34 
/usr/lib/perl/ptest/AUTHORS
-r--r--r--    1 xuser   xuser                    6321 Jan 31  2014 
/usr/lib/perl/ptest/Artistic
-r--r--r--    1 xuser   xuser                    3168 Jan 31  2014 
/usr/lib/perl/ptest/Changes
-r-xr-xr-x    1 xuser   xuser                  552838 Oct 31 15:34 
/usr/lib/perl/ptest/Configure

Further, this one even manages to get the user:group names from the host:

llc[12]$ rpm -qlvp 
tmp/deploy/rpm/cortexa8hf_vfp_neon/libgcc-s-dev-4.9.1-r0.0.cortexa8hf_vfp_neon.rpm 
| grep pab
lrwxrwxrwx    1 pab     pab                        22 Oct 31 15:17 
/usr/lib/arm-poky-linux -> arm-poky-linux-gnueabi

My tentative conclusion is that these new behaviors aren't related to 
the pseudo falling back to host /etc files, but probably instead by 
files getting installed (and in one case somehow packaged) without using 
pseudo.  I have no idea why that's happening, but it does appear 
something's not working right.

Peter