Description of problem: Samba 3 opens fds as root, then setuids to the connecting user. Trying to access these fds are falsly checked against the new effective uid, instead of the old one at open time. Version-Release number of selected component (if applicable): GFS-kernel-2.6.9-35.5 How reproducible: always Steps to Reproduce: 1.open("somefile", O_RDWR, 0600) as root 2.switch to a user with set(res)uid/gid, who doesn't have write access to this file 3.Try to expand this file with ftruncate (note: the above is what samba does and fails, simply writing to that file should also fail) Actual results: The ftruncate fails Expected results: ftruncate should succeed. Additional info: This bug is exhibited by Samba when placing its *.tdb database files containing metadata about locks, connections, crypt tokens etc. on a GFS filesystem. The latter trick is vital for creating a poor-man's-clustered-samba solution. See also the mail thread in the URL.
Actually, it seems like only setattr requests are incorrectly checked. Reads and writes are POSIX compliant.
Do you mean setxattr from the POSIX ACL draft? Perhaps that one, too, but already ftruncate fails (resizing a file).
I actually mean system calls that use the filesystem specific setattr hook in VFS (which is linked to gfs_setattr in gfs. This is where the bug is). Truncating a file is one such call. Sorry for not being clear about that. The only question I have is why IS gfs checking permissions in gfs_setattr. I'm trying to make sure that there isn't some reason why it is necessary. I currently can't see one. If it's unnecessary, I'll just remove the check. If it is... that's a little more complicated.
I pulled the check from gfs_setattr
Is this as trivial to fix on RHEL4U1 (or U2) as it sounds? Otherwise could you provide a patch? I'd like to continue tetsing Samba on GFS. Thanks for the fast fix!
Created attachment 119371 [details] patch to remove invalid permission checking Here is a patch that should apply cleanly to any RHEL4 kernel, that will fix this
You can also checkout the RHEL4 branch of CVS, which has this change. Unfortunately it is too late in the release cycle to restart QA. So unless the U2 kernel changes (which will force us to retest anyway) this fix will not make it into U2.
This fix will not make the U2 release.
Does that mean that it will only apper on U3, or will there be updated GFS-kernel packages before that? If the fix takes too long to surface rhn channels I would repackage GFS-kernel for RHELU2 with the patch from comment #6. I could also make them unofficially available through ATrpms, if there is interest.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2006-0169.html