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
--
--
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
