Bug 143093
| Summary: | nfs client lenient on chown semantics | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Emmanuel Thomé <emmanuel.thome+bugzilla> | ||||||||
| Component: | kernel | Assignee: | Dave Jones <davej> | ||||||||
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Brian Brock <bbrock> | ||||||||
| Severity: | medium | Docs Contact: | |||||||||
| Priority: | medium | ||||||||||
| Version: | 5 | CC: | davej, pfrields, wtogami | ||||||||
| Target Milestone: | --- | Keywords: | FutureFeature | ||||||||
| Target Release: | --- | ||||||||||
| Hardware: | All | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | Enhancement | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2006-11-24 22:50:40 UTC | Type: | --- | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Attachments: |
|
||||||||||
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. 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. 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. 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. 2.6.14-1.1637_FC4 has been released as an update for FC4. Please retest with this update, as a large amount of code has been changed in this release, which may have fixed your problem. Thank you. This is a mass-update to all currently open kernel bugs. A new kernel update has been released (Version: 2.6.15-1.1830_FC4) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO_REPORTER state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. Thank you. This bug hasn't been fixed as of 2.6.15-1.1830_FC4. Let me recall that a fix is suggested, and there's absolutely no reason to expect the bug to spontaneously fix itself without considering the suggested fix. I'd like to have a *human* answer the question of whether this enhancement is wanted or not. I'd be perfetcly OK if the answer were "don't care" -- that's acceptable for a RFE. Thank you. (dummy comment -- I fear the bug will remain in NEEDINFO_REPORTER state as long as I don't reply with the original reporting account). Would it be possible to get a tethereal or tcpdump trace of the network traffic? Created attachment 135059 [details]
transaction with chown allowed
In this transaction, uid 1726 tries to chown to uid 1500 the file
/thome/info.doc on the nfs volume. That file is owned by uid 1726. As per
POSIX, this shouldn't pass but it does.
Created attachment 135061 [details]
transaction with chown denied
same transaction with the suggested patch applied. ``permission denied''
returns to userland.
Created attachment 135068 [details] same, but denial by a well-behaving server This is still the same transaction pattern, but with another server, which behaves as one would expect: an error code is returned. All tests are with client 2.6.17-1.2174_FC5 As said, the bug really lies in the server letting pass the request in attachment 135059 [details]. The point is that maybe it wouldn't hurt to have the client block a request that POSIX forbids (up to you, really). [This comment added as part of a mass-update to all open FC4 kernel bugs] FC4 has now transitioned to the Fedora legacy project, which will continue to release security related updates for the kernel. As this bug is not security related, it is unlikely to be fixed in an update for FC4, and has been migrated to FC5. Please retest with Fedora Core 5. Thank you. A new kernel update has been released (Version: 2.6.18-1.2200.fc5) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. In the last few updates, some users upgrading from FC4->FC5 have reported that installing a kernel update has left their systems unbootable. If you have been affected by this problem please check you only have one version of device-mapper & lvm2 installed. See bug 207474 for further details. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. If this bug has been fixed, but you are now experiencing a different problem, please file a separate bug for the new problem. Thank you. This bug has been mass-closed along with all other bugs that have been in NEEDINFO state for several months. Due to the large volume of inactive bugs in bugzilla, this is the only method we have of cleaning out stale bug reports where the reporter has disappeared. If you can reproduce this bug after installing all the current updates, please reopen this bug. If you are not the reporter, you can add a comment requesting it be reopened, and someone will get to it asap. Thank you. |
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: