[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
chown (GNU fileutils) 4.0.27 : problem with --dereference ?
From: |
Maxime Froment |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- chown (GNU fileutils) 4.0.27 : problem with --dereference ?,
Maxime Froment <=