[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Coreutils 5.93 patched with 5.91 POSIX ACL patch test results - Upda
From: |
Bob Proulx |
Subject: |
Re: Coreutils 5.93 patched with 5.91 POSIX ACL patch test results - Update |
Date: |
Fri, 2 Dec 2005 10:32:49 -0700 |
User-agent: |
Mutt/1.5.9i |
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