update: chown fails to ignore symbolic links during recursive directory transversals

[Mark Brand]

Yesterday I reported that chown fails to ignore symbolic links during 
recursive directory transversals. For convenience, here is the text of 
my report, followed by updated information.

<snip>
> version: coreutils-5.2.1-32.rpm (from SuSE 9.2). Linux kernel 2.6.11.1 
> (kernel.org version).
> reiserfs.
>
> Quoting from the chown man page:
> > The following options modify how a hierarchy is traversed when the  -R  option  
> > is
> >        also specified.  If more than one is specified, only the final one takes 
> > effect.
> >
> >        -H     if a command line argument is a symbolic link to a directory, 
> > traverse it
> >
> >        -L     traverse every symbolic link to a directory encountered
> >
> >        -P     do not traverse any symbolic links (default)
>
> The info page for chown agrees:
> > `-R'
> > `--recursive'
> >      Recursively change ownership of directories and their contents.
> >
> > `-H'
> >      If `--recursive' (`-R') is specified and a command line argument
> >      is a symbolic link to a directory, traverse it.  *Note Traversing
> >      symlinks::.
> >
> > `-L'
> >      In a recursive traversal, traverse every symbolic link to a
> >      directory that is encountered.  *Note Traversing symlinks::.
> >
> > `-P'
> >      Do not traverse any symbolic links.  This is the default if none
> >      of `-H', `-L', or `-P' is specified.  *Note Traversing symlinks::.
>
>
> The actual default behavior of chown appears to be to recursively follow
> symbolic links. To wit:
>
> haydn:~ # mkdir sandbox
> haydn:~ # cd sandbox/
> haydn:~/sandbox # mkdir -p a/aa/aaa
> haydn:~/sandbox # touch foo
> haydn:~/sandbox # mkdir b
> haydn:~/sandbox # cd a/aa/aaa/
> haydn:~/sandbox/a/aa/aaa # ln -s ../../../foo foo
> haydn:~/sandbox/a/aa/aaa # ln -s ../../../b b
> haydn:~/sandbox/a/aa/aaa # cd ../../..
> haydn:~/sandbox # ls -l
> total 2
> drwxr-xr-x   4 root root  120 Mar  9 10:03 .
> drwx------  37 root root 2304 Mar  9 10:02 ..
> drwxr-xr-x   3 root root   72 Mar  9 10:03 a
> drwxr-xr-x   2 root root   48 Mar  9 10:03 b
> -rw-r--r--   1 root root    0 Mar  9 10:03 foo
> haydn:~/sandbox # chown -R nobody:users a
> haydn:~/sandbox # ls -l
> total 2
> drwxr-xr-x   4 root   root   120 Mar  9 10:03 .
> drwx------  37 root   root  2304 Mar  9 10:02 ..
> drwxr-xr-x   3 nobody users   72 Mar  9 10:03 a
> drwxr-xr-x   2 nobody users   48 Mar  9 10:03 b
> -rw-r--r--   1 nobody users    0 Mar  9 10:03 foo
>
> Moreover, there doesn't seem to be any way of invoking chown so that it
> operates recursively on a directory tree but ignores (doesn't follow)
> symbolic links.
</snip>

Discussion of this issue with Jim Meyering <address@hidden> and Paul 
Eggert <address@hidden> this morning considered a number of 
explanations:

-chown has a bug in coreutils 5.2.1
-there is something wrong with the kernel that affects the behavior of chown
-there is something wrong with Suse 9.2  coreutils-5.2.1-32.rpm

I'm using the plain vanilla kernel 2.6.11.1 from kernel.org. I can 
reproduce the problem with this kernel and also with Suse 
kernel-default-2.6.8-24.11.rpm. I also note that "chmod" behaves as 
expected in contrast to "chown" (while they are both presumably based on 
the same libraries and kernel facilities).

Additionally, on the suggestion of Paul Eggert, I built
ftp://alpha.gnu.org/gnu/coreutils/coreutils-5.3.0.tar.gz and tested the
new chown on the same machine with kernel.org kernel 2.6.11.1. With this
configuration, chown behaves correctly. The chown built from
ftp://ftp.gnu.org/gnu/coreutils/coreutils-5.2.1.tar.gz also works correctly.

This is all good evidence that the kernel is not at fault. The problem 
also appears to be unique to the Suse rpm coreutils-5.2.1. I have not 
tested other Suse versions.

I then did:

rpmbuild --rebuild --target i686 coreutils-5.2.1-32.src.rpm
rpm -Uhv --force /usr/src/packages/RPMS/i686/coreutils-5.2.1-32.i686.rpm

The problem still manifests itself, which seems to rule out a library 
incompatibility.

I have filed a bug about this with Suse, but I'm posting this update 
here as well since this issue means that running chown can have very 
serious unintended consequences.


Regards,
Mark Brand