Bug 171131 - nfs client lenient on chown semantics
nfs client lenient on chown semantics
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Steve Dickson
Brian Brock
: FutureFeature
Depends On:
  Show dependency treegraph
Reported: 2005-10-18 09:37 EDT by Jindrich Novy
Modified: 2013-07-02 19:10 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-03-13 10:38:54 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jindrich Novy 2005-10-18 09:37:22 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)
Gecko/20041111 Firefox/1.0

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);
        if (error)
                return error;

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):

How reproducible:

Steps to Reproduce:
1. n/a

Additional info:

-- Additional comment from davej@redhat.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'.

Thank you.

-- Additional comment from Emmanuel.Thome+bugzilla@loria.fr on 2005-07-16 05:32
EST --
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
i386 GNU/Linux

Which exactly is the patch included in this update that you expected could fix
the issue ?



-- Additional comment from davej@redhat.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 ( 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.


Comment 2 Daniel Riek 2006-03-13 10:38:54 EST
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.


Note You need to log in before you can comment on or make changes to this bug.