Reminder: chown (GNU fileutils) 4.0.33 : problem with --dereference ?

[Maxime Froment]

This is a reminder for a bug report (with patch) concerning chown.
Note that this was submitted for version 4.0.27, but as of version
4.0.33 it does not appear to be fixed. The patch can still be applied 
on the later source.

If it appeared that the behavior reported as buggy is in fact a
feature, please let me know so I will stop resending the message.

/* --------------------------------------------------------------
            Maxime Froment     <address@hidden>         
   -------------------------------------------------------------- */

--- Begin Message --- Subject: chown (GNU fileutils) 4.0.27 : problem with --dereference ? Date: Thu, 26 Oct 2000 16:34:37 +0900 User-agent: Wanderlust/1.1.1 (Purple Rain) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.1 (patch 10) (Capitol Reef) (i686-pc-linux)

Our QA team had reported a strange behaviour with chown when using the
--dereference option on a symbolic link in a particular situation. 

Namely, when trying to give ownership of the referenced file to the
owner of the symbolic link by using chmod --dereference on the symbolic
link, nothing even occurs.

For instance (logged in as root):

  # chown --version
  chown (GNU fileutils) 4.0.27
  Written by David MacKenzie.

  Copyright (C) 2000 Free Software Foundation, Inc.
  This is free software; see the source for copying conditions.  There is NO
  warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

  # ls -l
  total 4
  -rw-r--r--   1 user1    users           5 Oct 26 14:33 regularfile
  lrwxrwxrwx   1 user1    users          11 Oct 26 14:34 symlink -> regularfile

  # chown -v user2 symlink ; ls -l
  owner of symlink changed to user2
  total 4
  -rw-r--r--   1 user1    users           5 Oct 26 14:33 regularfile
  lrwxrwxrwx   1 user2    users          11 Oct 26 14:34 symlink -> regularfile

  # chown -v --dereference user2 symlink; ls -l
  owner of symlink retained as user2
  total 4
  -rw-r--r--   1 user1   users           5 Oct 26 14:33 regularfile
  lrwxrwxrwx   1 user2   users          11 Oct 26 14:34 symlink -> regularfile

If my understanding of the option is correct, the last command should
have changed the owner of 'regularfile' to 'user2'.

A quick inspection of the source shows that the ownership of the file
specified on the command line is checked by a call to lstat before the
call to lchown or chown is done; the call to (l)chown is only actually
performed if the new ownership differs from the original ownership. 
It seems that the problem resides in the fact that when the --dereference
option is specified with a symbolic link for argument, the new
ownership will then be compared to the original ownership of the symbolic
link, instead of the original ownership of the target referenced file.

I have included a small patch that seems to correct the above
behavior, but I am not entirely confident on how it rates in terms in
correctness and cleverness (it adds a supplementary call to stat...).

If this is expected behaviour, it is a little puzzling, and it
does not seem to get a justification on the info page. I surely would
like to be enlightened a little bit about it.

Regards,

Maxime Froment

fileutils-4.0.27-chown_dereference.patch
Description: Binary data

--- End Message ---