Red Hat Bugzilla – Bug 169039
GFS POSIX bug: opened fds not pertaining access permissions after setuid
Last modified: 2010-01-11 22:07:30 EST
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):
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
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)
The ftruncate fails
ftruncate should succeed.
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
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
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.