GNU bug report logs - #29788
chown: recursive operation with "-H" flag does not work as documented

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 29788 in the body.
You can then email your comments to 29788 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Michael Orlitzky <michael <at> orlitzky.com>
To: bug-coreutils <at> gnu.org
Subject: chown: recursive operation with "-H" flag does not work as documented
Date: Wed, 20 Dec 2017 13:24:14 -0500

The documentation for the "-H" flag to chown says,

  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

This is not doing what I think it should do. In a terminal, as my "mjo"
system user, I can run,

  $ mkdir foo
  $ mkdir bar
  $ ln -s ../bar foo/baz
  $ sudo chown --verbose --recursive -H root foo

which outputs...

  changed ownership of 'foo/baz' from mjo to root
  changed ownership of 'foo' from mjo to root

However, the path "foo/baz" was not passed on the command-line, and
chown did in fact follow the symlink,

  $ ls -l | grep bar
  drwxr-xr-x  2 root mjo 4.0K 2017-12-20 13:19 bar

as evidenced by the fact that "bar" was created as mjo:mjo.

Message #12 received at 29788-done <at> debbugs.gnu.org (full text, mbox):

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Michael Orlitzky <michael <at> orlitzky.com>, 29788-done <at> debbugs.gnu.org
Subject: Re: bug#29788: chown: recursive operation with "-H" flag does not
 work as documented
Date: Wed, 20 Dec 2017 21:58:57 +0100

tag 29788 notabug
stop

On 12/20/2017 07:24 PM, Michael Orlitzky wrote:
> The documentation for the "-H" flag to chown says,
> 
>    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
> 
> This is not doing what I think it should do. In a terminal, as my "mjo"
> system user, I can run,
> 
>    $ mkdir foo
>    $ mkdir bar
>    $ ln -s ../bar foo/baz
>    $ sudo chown --verbose --recursive -H root foo
> 
> which outputs...
> 
>    changed ownership of 'foo/baz' from mjo to root
>    changed ownership of 'foo' from mjo to root
> 
> However, the path "foo/baz" was not passed on the command-line, and
> chown did in fact follow the symlink,
> 
>    $ ls -l | grep bar
>    drwxr-xr-x  2 root mjo 4.0K 2017-12-20 13:19 bar
> 
> as evidenced by the fact that "bar" was created as mjo:mjo.

I think there is something else going on you didn't consider:

      --dereference      affect the referent of each symbolic link (this is
                         the default), rather than the symbolic link itself

The -H option does not affect 'foo/baz' (or the target it references),
but only the command line arg 'foo'.  So the test case for -H is:

  $ mkdir bar bar/baz
  $ ln -s bar foo

  $ sudo chown --verbose --recursive -H root foo
  changed ownership of 'foo/baz' from berny to root
  changed ownership of 'foo' from berny to root

  $ find . -ls
  4014266      4 drwxr-xr-x   3  berny    users        4096 Dec 20 21:50 .
  4014269      4 drwxr-xr-x   3  root     users        4096 Dec 20 21:50 ./bar
  4014271      4 drwxr-xr-x   2  root     users        4096 Dec 20 21:50 ./bar/baz
  4014272      0 lrwxrwxrwx   1  berny    users           3 Dec 20 21:50 ./foo -> bar

Without -H, chown would not dereference 'foo', and change the ownership of
the symlink (on systems which support this):

  $ sudo chown --verbose --recursive root foo
  changed ownership of 'foo' from berny to root

  $ find . -ls
  4014266      4 drwxr-xr-x   3  berny    users        4096 Dec 20 21:51 .
  4014269      4 drwxr-xr-x   3  berny    users        4096 Dec 20 21:51 ./bar
  4014271      4 drwxr-xr-x   2  berny    users        4096 Dec 20 21:51 ./bar/baz
  4014272      0 lrwxrwxrwx   1  root     users           3 Dec 20 21:51 ./foo -> bar

Thus, I think this not a bug in chmod or the documentation, but in the
your expectations.  Therefore, I'm marking this as not-a-bug in our bug
tracker.  Of course, you are welcome to continue the discussion, and if
needed we can reopen this issue at a later point.

Have a nice day,
Berny

Message #15 received at 29788-done <at> debbugs.gnu.org (full text, mbox):

From: Michael Orlitzky <michael <at> orlitzky.com>
To: 29788-done <at> debbugs.gnu.org
Subject: Re: bug#29788: chown: recursive operation with "-H" flag does not
 work as documented
Date: Wed, 20 Dec 2017 16:26:56 -0500

On 12/20/2017 03:58 PM, Bernhard Voelker wrote:
> 
> I think there is something else going on you didn't consider:
> 
>        --dereference      affect the referent of each symbolic link (this is
>                           the default), rather than the symbolic link itself
> 
> ...
> 
> Thus, I think this not a bug in chmod or the documentation, but in the
> your expectations.  Therefore, I'm marking this as not-a-bug in our bug
> tracker.  Of course, you are welcome to continue the discussion, and if
> needed we can reopen this issue at a later point.
> 

Thank you, you might be right. To explain how I wound up in this
situation, what I was actually running was,

  $ chown --recursive --dereference root foo

which emits an error:

  chown: -R --dereference requires either -H or -L

At that point, I consulted the documentation to see how "-H" and "-L"
differ:

  -H  if a command line argument is a symbolic link  to  a  directory,
      traverse it

  -L  traverse every symbolic link to a directory encountered

By way of omission I expected -H not to follow directory symlinks that
weren't explicitly passed, but I can see how the interpretation could go
either way. The choice of "-H" or "-L" adds to the "--dereference"
option, whereas I thought it was asking me to choose (only) one of the
two modes of operation.

Thanks for your time.

Message #18 received at 29788 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: 29788 <at> debbugs.gnu.org, mail <at> bernhard-voelker.de, michael <at> orlitzky.com
Subject: Re: bug#29788: chown: recursive operation with "-H" flag does not
 work as documented
Date: Wed, 20 Dec 2017 13:52:17 -0800

On 12/20/2017 12:58 PM, Bernhard Voelker wrote:
> Thus, I think this not a bug in chmod or the documentation, but in the
> your expectations.

I think his expectations are what POSIX requires. For chown -H -R, POSIX 
says that if "a symbolic link referencing a file of type directory is 
specified on the command line, /chown/ shall change the user ID (and 
group ID, if specified) of the directory referenced by the symbolic link 
and all files in the file hierarchy below it." The clear implication in 
context is that -H should mean --dereference at the top level, and 
--no-dereference at lower levels. Which is pretty much what he was 
expecting.

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/chown.html

Admittedly the POSIX spec is not that easy to understand here.

Message #21 received at 29788 <at> debbugs.gnu.org (full text, mbox):

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Paul Eggert <eggert <at> cs.ucla.edu>, 29788 <at> debbugs.gnu.org,
 michael <at> orlitzky.com
Subject: Re: bug#29788: chown: recursive operation with "-H" flag does not
 work as documented
Date: Thu, 21 Dec 2017 00:07:46 +0100

On 12/20/2017 10:52 PM, Paul Eggert wrote:
> For chown -H -R, POSIX
> says that if "a symbolic link referencing a file of type directory is
> specified on the command line,/chown/  shall change the user ID (and
> group ID, if specified) of the directory referenced by the symbolic link
> and all files in the file hierarchy below it." The clear implication in
> context is that -H should mean --dereference at the top level, [...]

I agree here.

> [...] and --no-dereference at lower levels.

I read this different: --dereference is still the default in the
OPs example 'chown -vRH root foo' as -h|--no-dereference was not
explicitly passed.

After all, I somehow have the feeling that the problem is two-fold:
a) The ownership of which file is changed? The symlink or the target?
b) Shall chown follow the symlink or not?
Without a dedicated --follow|--no-follow, it will be impossible to
satisfy all combinations of expected behavior.

Anyway, it seems hard to choose the right combination without knowing
if the command line argument is a symbolic link (and points to a valid
and accessible directory or not) or another file type.

Have a nice day,
Berny

Message #24 received at 29788 <at> debbugs.gnu.org (full text, mbox):

From: Michael Orlitzky <michael <at> orlitzky.com>
To: 29788 <at> debbugs.gnu.org
Subject: Re: bug#29788: chown: recursive operation with "-H" flag does not
 work as documented
Date: Wed, 20 Dec 2017 18:12:59 -0500

On 12/20/2017 04:52 PM, Paul Eggert wrote:
> On 12/20/2017 12:58 PM, Bernhard Voelker wrote:
>> Thus, I think this not a bug in chmod or the documentation, but in the
>> your expectations.
> 
> I think his expectations are what POSIX requires. For chown -H -R, POSIX 
> says that...

This is where I started off, but POSIX doesn't say anything about the
"--dereference" flag. When chown told me to pick either "-H" or "-L", I
thought it was asking me to pick one mode of operation, either

  a) chown -R -L, or
  b) chown -R -H

In fact, it was asking me to choose one of

  c) chown --dereference -R -L, or
  d) chown --dereference -R -H

Should "chown --dereference" be equivalent to "chown"? If so, then

  chown --dereference -R -H = chown -R -H

is specified by POSIX.

At this point, you could talk me into either interpretation.

Message #27 received at 29788-done <at> debbugs.gnu.org (full text, mbox):

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Michael Orlitzky <michael <at> orlitzky.com>, 29788-done <at> debbugs.gnu.org
Subject: Re: bug#29788: chown: recursive operation with "-H" flag does not
 work as documented
Date: Thu, 21 Dec 2017 00:19:41 +0100

On 12/20/2017 10:26 PM, Michael Orlitzky wrote:
>    $ chown --recursive --dereference root foo
> 
> which emits an error:
> 
>    chown: -R --dereference requires either -H or -L

Hmm, this looks inconsistent as well: --dereference is the
default if neither --dereference nor -h|--no-dereference are
specified, but 'chown -R user dir' does not require -H or
-L.

chown(1) hasn't been changed regarding this behavior since
2006 (coreutils-6.8), so this is obviously a rare edge case.

FWIW, the test-suite for chown lacks exactly that case.

Have a nice day,
Berny

Message #30 received at 29788 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Michael Orlitzky <michael <at> orlitzky.com>, 29788 <at> debbugs.gnu.org
Subject: Re: bug#29788: chown: recursive operation with "-H" flag does not
 work as documented
Date: Thu, 21 Dec 2017 08:58:18 -0800

On 12/20/2017 03:12 PM, Michael Orlitzky wrote:
> This is where I started off, but POSIX doesn't say anything about the
> "--dereference" flag.

Yes, well, a fundamental problem here is that POSIX is confused. The -H, 
-L, and -P options are clearly intended to control whether symlinks are 
followed, and the -h option is also intended to control the same thing, 
and POSIX doesn't say what happens when the two conflict. For example, 
'chown -RHh symlink-to-dir' clearly conflicts (-L means command-line 
symlinks to directories are followed, whereas -h means they are not), 
and POSIX does not say how to resolve the conflict.

The situation is further complicated by the fact that GNU chown treats 
-h as an option that affects all files, not just command-line files as 
POSIX would have it. And that GNU chown has a --dereference option that 
is intended to be the inverse of the -h option.

I think the *intent* of the GNU code is that -h/--dereference controls 
only whether lchown or chown is used, and that -H/-L/-P control only 
whether symlinks to directories are followed in a recursive chown. But 
(a) that's not what the code really does, (b) the intent does not 
conform to POSIX, (c) the code does not conform to POSIX either, and (d) 
as mentioned above, POSIX is broken. It's a true mess.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.