Re: [nfs-discuss] mount.nfs: access denied by server

[Nicolas Williams <Nicolas.Williams-xsfywfwIY+M@public.gmane.org>]

On Tue, Aug 25, 2009 at 07:20:16PM -0400, Trond Myklebust wrote:
> I was thinking of the case in which /foo/bar is not actually a mount
> point. :-)

Looking at code we have

    nfs4_secinfo_recov() ->
       nfs4_secinfo_vnode() ->
          nfs4_secinfo_fh_otw() ->
	     secinfo_update()

And as you can see nfs4_secinfo_vnode() calls nfs4_secinfo_fh_otw() to
get the SECINFO for the affected FH, but, nfs4_secinfo_fh_otw() updates
the mount's server info.

Which means that WRONGSEC -> SECINFO -> updates the entire mount's sec.

I.e., if you have:

 - server:/foo w/ sec=krb5
 - server:/foo/bar in the _same_ filesystem (i.e., with same fsid) and
   sec=krb5i

the client will probably thrash if you mount server:/foo because each
WRONGSEC from accessing server:/foo/baz will cause the client to update
the entire mount, which will lead to WRONGSEC from accessing
server:/foo/bar, which will lead to WRONGSEC from accessing
server:/foo/baz, which ...

> If we all agree that the server can only remove security flavours when
> crossing a mount point, then all is well, however the protocol doesn't
> strictly speaking say that has to be the case.

I agree, that sounds like a very good rule for now.

One could also argue that clients should handle this on a per-directory
basis, not per-mount.  But first we'd have to agree that it's a good
idea to have nested "shares" in the same filesystem.

> That worries me...

Me too.

Nico
--