On 10/13/2014 05:35 PM, Peter Seebach wrote:
On Mon, 13 Oct 2014 17:29:26 -0500
"Peter A. Bigot" <p...@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
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
