On Friday May 2, bfields@xxxxxxxxxxxx wrote: > On Fri, May 02, 2008 at 12:04:53PM -0400, Trond Myklebust wrote: > > > > AFAICS, the real problem here is that nfsd is dropping its privileged > > mode too early. Why can't you call reconnect_path() using nfsd's root > > permissions instead of dropping permissions checks altogether? > > That's an interesting idea. > > As I understand it, nfsd sets the current task's credentials only once, > in nfsd_setuser, called from fh_verify(). The change lingers around > until next time we do fh_verify(). So in addition to moving the > nfsd_setuser() call to after the lookup of the dentry (so after > exportfs_decode_fh(), we'd also need to add an explicit acquisition of > whatever permissions we need before we do that lookup. I have substantial sympathy for this approach. The "explicit acquisition" would probably just be current->cap_effective = cap_raise_nfsd_set(current->cap_effective, current->cap_permitted); (from nfsd_setuser). This should reclaim the RACOVERRIDE permission which should be enough. The one problem that I see is that it would invalidate the err = permission(parent->d_inode, MAY_EXEC, NULL); check in nfsd_acceptable. Currently if we have "subtree_check" set, not only must the file be in the right subtree of the filesystem, but the user accessing the file must have 'x' permission on every parent directory. For that test to work we must have already set the effective uid correctly. Now it could be argued that this permission test is really a dumb idea that buys nothing and costs much. And if you were to queue a patch to get rid of it, I doubt you would get any objections .... certainly not from me :-) NeilBrown -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
