2008-05-05 02:26:32

by NeilBrown

[permalink] [raw]
Subject: Re: [PATCH] exportfs: fix incorrect EACCES in reconnect_path()

On Friday May 2, [email protected] 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