Bug 171131 - nfs client lenient on chown semantics
Summary: nfs client lenient on chown semantics
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel
Version: 4.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Steve Dickson
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-10-18 13:37 UTC by Jindrich Novy
Modified: 2013-07-02 23:10 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-03-13 15:38:54 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Jindrich Novy 2005-10-18 13:37:22 UTC
+++ 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
have CAP_CHOWN

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):
2.6.9-1.681_FC3

How reproducible:
Always

Steps to Reproduce:
1. n/a
2.
3.
    

Additional info:

-- Additional comment from davej 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 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 ?

Regards,

E.

-- Additional comment from davej 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 (2.6.13.2). 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.

Thanks.


-- Additional comment from Emmanuel.Thome 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.

Regards,

E.

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

Closing WONTFIX


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