Re: Coreutils 5.93 patched with 5.91 POSIX ACL patch test results - Update

[Bob Proulx]

Albe wrote:
> The following is the required debug dump of the fail-perm on the 
> original slackware 10.2 virtual machine:

Thank you.  That is useful information.

> make: Entering directory `/root/coreutils-5.93/tests/cp'
> make  check-TESTS
> make[1]: Entering directory `/root/coreutils-5.93/tests/cp'
> + cp --version
> cp (GNU coreutils) 5.93

Good.

> ...
> + PRIV_CHECK_ARG=require-non-root
> + . ./../priv-check
> ++ case "$PRIV_CHECK_ARG" in
> ++ who='by an unprivileged user'
> +++ id -u
> ++ my_uid=0

You are running the test as root.

> ++ test 0 = 0
> ++ case $my_uid in
> ++ test 0 = 0
> ++ : nobody

  : ${NON_ROOT_USERNAME=nobody}

The test is converting to the "nobody" user.

> +++ id -u nobody
> ++ coreutils_non_root_uid=99

  coreutils_non_root_uid=`id -u $NON_ROOT_USERNAME`

> ++ test 0 = 0
> ++ test 99 = 0

  test "$coreutils_non_root_uid" = 0 && \

The nobody user is not uid 0 so continue.

> ++ give_msg=no
> ++ case $PRIV_CHECK_ARG:$my_uid in
> ++ setuidgid nobody test -w .

    exec setuidgid $NON_ROOT_USERNAME env PATH="$PATH" $0

Run the setuidgid compiled from coreutils and overlay it on top of
this currently running shell replacing it.  The program will change
the uid and gid to the non-root user and then run the test again.

> ++ exec setuidgid nobody env 
> PATH=/root/coreutils-5.93/tests/cp/../../src:/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/games:/opt/www/htdig/bin:/usr/lib/java/bin:/usr/lib/java/jre/bin:/opt/kde/bin:/usr/lib/qt/bin:/usr/share/texmf/bin
>  
> ./fail-perm

This is the second time through the program.  At this point we are not
root.  At this point we are the nobody user.

> ...
> + . ./../priv-check
> ++ case "$PRIV_CHECK_ARG" in
> ++ who='by an unprivileged user'
> +++ id -u
> ++ my_uid=99

Not root.  Now the nobody user.

> ++ test 0 = 0
> ++ case $my_uid in
> ++ test 99 = 0
> ++ give_msg=no
> ++ case $PRIV_CHECK_ARG:$my_uid in
> ++ test no = yes
> ++ pwd
> + pwd=/root/coreutils-5.93/tests/cp
> ++ echo ./fail-perm
> ++ sed 's,.*/,,'
> + t0=fail-perm.tmp
> + tmp=fail-perm.tmp/15251
> + trap 'status=$?; cd $pwd; chmod -R u+rwx $t0; rm -rf $t0 && exit 
> $status' 0
> + trap '(exit $?); exit' 1 2 13 15
> + framework_failure=0

This is where things get interesting.  Here is the source:

  framework_failure=0
  mkdir -p $tmp || framework_failure=1
  cd $tmp || framework_failure=1

But the trace diverges from expected behavior here.

> + mkdir -p fail-perm.tmp/15251

The 'mkdir -p' returned success.  We see this because we do not see
the framewrk_failure=1 from the "|| framework_failure=1" part.

> + cd fail-perm.tmp/15251
> ./fail-perm: line 17: cd: fail-perm.tmp/15251: Not a directory
> + framework_failure=1

But even though the mkdir -p returned success the shell is unable to
chdir to the directory.  It failed and set framework_failure=1.

> + mkdir D D/D
> mkdir: cannot create directory `D': File exists
> mkdir: cannot create directory `D/D': File exists
> + framework_failure=1

This also failed.  But it failed because it created a directory in a
different location than the test frame expected.  This exposes a
problem with the test frame.  If the above cd fails then it should not
continue and create files outside of where it was expecting to be.

> + touch D/a
> + chmod 0 D/a
> + chmod 500 D

These succeeded.  (Strangely if the other parts failed.)  The test
frame has now created a file D/a that is not readable in a directory
mode "drwx------".  But it is in the wrong location.

> + test 1 = 1
> + echo 'failure in testing framework'
> failure in testing framework
> + exit 1

The test frame exits and tries to clean up.  The EXIT trap set earlier
is now executed.

> + status=1

The test failed.

> + cd /root/coreutils-5.93/tests/cp
> ./fail-perm: line 26: cd: /root/coreutils-5.93/tests/cp: Not a directory

How can this fail?  The code is:

  pwd=`pwd`
  t0=`echo "$0"|sed 's,.*/,,'`.tmp; tmp=$t0/$$
  trap 'status=$?; cd $pwd; chmod -R u+rwx $t0; rm -rf $t0 && exit $status' 0

It is returning to the saved pwd location that it was at previously.
But the cd to the saved location fails!  I cannot deduce why this
command is not functioning.

> + chmod -R u+rwx fail-perm.tmp
> + rm -rf fail-perm.tmp

The test frame removes the temporary directory it attempted to created
earlier.  However in this particular case I believe the directory was
already in existence from a previous run because the 'mkdir -p' failed
when trying to create a subdirectory of it.

Next steps:

You are working with ACLs and the upstream coreutils is not designed
to handle them at this time.  (Soon.  But not at this moment.)  I
believe that is the root cause of your problem.

You are compiling and testing as the root user.  Hmm...  I recommend
never to compile programs as root.  There is just too much dependence
that there are no bugs.  It is much better to compile as a normal
non-root user and to test that way too.  The test frame will detect
this and then run the non-root tests.  Then after those are successful
it is useful to run the framework as the root user.  Do that last.  I
recommend using sudo from the normal user account.  Run the tests with
'sudo make check'.  This would be a better way to work this problem.

For you the next step is to unpack in a clean location the pristine
sources as a non-root user.  Then configure, make, make check.

  # As a normal non-root user...
  tar x...  # Either gzip'd or bzip'd sources
  cd coreutils-5.93
  ./configure CFLAGS=-g  # since we are debugging
  make 2>&1 | tee make.out
  make check 2>&1 | tee make-check.out
  sudo make check 2>&1 | tee make-check-su.out  # Assuming sudo is configured

As a non-root user it should not be possible to create files that the
test frame cannot remove.  This should provide more consistent
behavior.

I believe that probably an ACL configuration exists on your system
that is preventing the "nobody" user from doing things that work on a
traditional non-ACL system.  By running as a non-root user to begin
with this problem can be avoided.  The NON_ROOT_USERNAME variable can
be set to the name of a non-root user to use for the test.

Thanks for reporting those problems.  It has exposed some problems in
the test frame which need to be improved.  I don't think this will
happen for the very next release however because that should be quite
soon.

Bob