On Fri, 14 Sep 2007 20:25:45 +1000 Greg Banks <gnb@xxxxxxx> wrote: > On Tue, Sep 04, 2007 at 10:37:04AM -0400, Jeff Layton wrote: > > If the ATTR_KILL_S*ID bits are set then any mode change is only for > > clearing the setuid/setgid bits. For NFS skip the mode change and > > let the server handle it. > > You're assuming the server will remove setuid and setgid bits on WRITE? > I don't see that behaviour specified in the RFC, at least for v3. > The RFC specifies a behaviour for the mtime attribute as a side > effect of WRITE, but says nothing about mode. This means server > implementations are free to clobber setuid or not. A quick experiment > shows that at least the Irix server will *NOT* clobber those bits. > So with an Irix server you've now lost this Linux-specific "security > feature". > > I'm curious about the reasons behind this change. You mention > credential issues; how exactly is it that you have the correct creds > to perform a WRITE rpc but not a SETATTR rpc? > Consider this case. user1 and user2 are both members of group "allusers": user1$ echo foo > foo user1$ chgrp allusers foo user1$ chmod 04770 foo user2$ echo bar >> foo On most local filesystems, this would work correctly. The end result would be a file with mode 0770 and the expected contents. On NFS though, the write by user2 fails. When the write is attempted, the kernel tries to squash the setuid bit using the credentials of user2, who's not allowed to change the mode. The write then fails because the setattr fails. There are other situations that are similar, but the bottom line is that the linux-specific security feature doesn't work in all cases, and in some situations it means that operations fail where they shouldn't. -- Jeff Layton <jlayton@xxxxxxxxxx> - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
