Red Hat Bugzilla – Bug 171131
nfs client lenient on chown semantics
Last modified: 2013-07-02 19:10:56 EDT
+++ This bug was initially created as a clone of Bug #143093 +++
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Description of problem:
posix mandates that to perform a chown(), the user must be root or
On nfs mounts, the current client code hands the check to the server.
If the server does its job correctly, things are OK.
I've got here a broken proprietary server which honors chown() as soon
as the originating uid is the same as the file's owner.
The braindamage carries over to the client.
I'd suggest adding the following on top of nfs_setattr (fs/nfs/inode.c):
error = inode_change_ok(inode, attr);
This would have the effect of not trying to honor requests that are
against the posix semantics.
Of course the server needs be fixed instead, but I'd love to have such
a double check.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
-- Additional comment from email@example.com on 2005-07-15 16:28 EST --
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which
may contain a fix for your problem. Please update to this new kernel, and
report whether or not it fixes your problem.
If you have updated to Fedora Core 4 since this bug was opened, and the problem
still occurs with the latest updates for that release, please change the version
field of this bug to 'fc4'.
-- Additional comment from Emmanuel.Thomefirstname.lastname@example.org on 2005-07-16 05:32
I still see the same behaviour with the latest kernel for fc4.
tate ~ $ touch foo
tate ~ $ ls -l foo
-rw-r--r-- 1 thome spaces 0 Jul 16 11:17 foo
tate ~ $ chown 0.0 foo
tate ~ $ ls -l foo
-rw-r--r-- 1 root root 0 Jul 16 11:17 foo
tate ~ $ uname -a
Linux tate.loria.fr 2.6.12-1.1398_FC4 #1 Fri Jul 15 00:52:32 EDT 2005 i686 i686
Which exactly is the patch included in this update that you expected could fix
the issue ?
-- Additional comment from email@example.com on 2005-09-30 03:03 EST --
Mass update to all FC4 bugs:
An update has been released (2.6.13-1.1526_FC4) which rebases to a new upstream
kernel (22.214.171.124). As there were ~3500 changes upstream between this and the
previous kernel, it's possible your bug has been fixed already.
Please retest with this update, and update this bug if necessary.
-- Additional comment from Emmanuel.Thome@inria.fr on 2005-10-18 04:43 EST --
kernel 2.6.13-1.1526_FC4 does not change the problem.
I really think that it is a matter of whether the fix is wanted or not. If it
is, then the fix I suggested is likely to be right IMHO.
This should be fixed in the proprietary server. Given the work needed and the
scope of a RHEL Update release, this won't be possible for us.