Re: coreutils 6.12 test-suite failure

[Jim Meyering]

Jarod Wilson <address@hidden> wrote:
> Hey there,
>
> Trying to reproduce a problem we (Red Hat) are seeing when building coreutils
> 6.12 in our build system[*], and I ran into a slightly different (and 100%
> reproduceable so far) test-suite failure. Log file attached. Build is done on
> a system with a 2.6.18-based kernel (RHEL5.2), building against 2.6.26-ish
> bits in a chrooted environment.
>
> [*] https://bugzilla.redhat.com/show_bug.cgi?id=442352

Hi Jarod,

Thanks for reporting that.
First off, those failures are all in root-only tests.

FAIL: misc/runcon-no-reorder.log (exit: 1)
==========================================
+ runcon root:system_r:unconfined_t:s0-s0:c0.c1023 true -j
+ diff -u out exp
...
-runcon: invalid context: root:system_r:unconfined_t:s0-s0:c0.c1023: No such 
file or directory
+runcon: runcon may be used only on a SELinux kernel

While I know the low-level cause (an strace from Ondrej Vasik
showed that /selinux/context doesn't exist in the chroot),
up to now, I hadn't worried about this failure, because I
thought it was specific to an (end-of-life) FC6 system.


FAIL: cp/cp-a-selinux.log (exit: 1)
===================================
...
+ mkdir mnt
+ mkfs -t ext2 -F blob
mkfs.ext2: No such file or directory
+ framework_failure
+ error_ 'failure in testing framework'

I have already prepared the tiny patch that will make this
failure skip the test rather than fail.


FAIL: cp/preserve-gid.log (exit: 1)
===================================
...
+ chown +0:+0 a0
+ create b0 1000 1000
+ echo b0
+ chown +1000:+1000 b0
+ create b1 1000 1001
+ echo b1
+ chown +1000:+1001 b1
+ create c0 0 1000
+ echo c0
+ chown +0:+1000 c0
+ create c1 0 1001
+ echo c1
+ chown +0:+1001 c1
+ t0 a0 0 0 cp
+ f=a0
+ shift
+ u=0
+ shift
+ g=0
+ shift
+ rm -f b
+ cp a0 b
++ stat -c '%u %g' b
+ s='0 103'
+ test 'x0 103' '!=' 'x0 0'
+ test 'x0 103' = 'x0 0'
+ echo './cp/preserve-gid: cp a0 b: 0 0 != 0 103'
./cp/preserve-gid: cp a0 b: 0 0 != 0 103
+ exit 1

This one was trickier.  I think it must be the case that
root's primary group is 103.  The test requires that it be 0.
Can you confirm?  (i.e., run id -g -- or better, id -a to get all of them)
I'll either adapt the test or make it skip in that case.


FAIL: rm/fail-2eperm.log (exit: 1)
==================================
...
++ setuidgid nobody env 
PATH=/builddir/build/BUILD/coreutils-6.12/src:/usr/lib64/ccache:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin
 rm --version
++ sed -n '1s/.* //p'
+ rm_version=6.10
+ case $rm_version in
+ echo './rm/fail-2eperm: cannot access just-built rm as user nobody'
./rm/fail-2eperm: cannot access just-built rm as user nobody
+ fail=1

FYI, this failure would have been avoided if the test had
been run as suggested in README:

    **********************
    Running tests as root:
    ----------------------

    If you run the tests as root, note that a few of them create files
    and/or run programs as a non-root user, `nobody' by default.
    If you want to use some other non-root username, specify it via
    the NON_ROOT_USERNAME environment variable.  Depending on the
    permissions with which the working directories have been created,
    using `nobody' may fail, because that user won't have the required
    read and write access to the build and test directories.
    I find that it is best to unpack and build as a non-privileged
    user, and then to run the following command as that user in order
    to run the privilege-requiring tests:

      sudo env PATH="$PATH" NON_ROOT_USERNAME=$USER make -k check-root

    If you can run the tests as root, please do so and report any
    problems.  We get much less test coverage in that mode, and it's
    arguably more important that these tools work well when run by
    root than when run by less privileged users.

Nonetheless, reports like this are common enough that I'll
make it so this test is skipped too, when this happens.

Patch for two of those coming right up.
I'll wait to hear back from you before addressing preserve-gid,
and I'm not yet sure what to do about runcon-no-reorder.