Subject: Re: [nfsv4] Global namespace for v4.1?

From: Julian Satran <[email-masked]>
Date: Tue, 13 Jan 2004 14:49:20 +0200

I don't think that using MOVED is good enough to builfd a global 
namespace.
There is nothing in it to insure global consistency (a single global 
namespace - that has the same structure everywhere even if some clients 
might not see some parts of the structure).
MOVED is a good mechanism when fss have really moved (like in load 
balancing!).
Brent's suggestion of using a name service is probably what is needed and 
whethere to build one in NFS or use a ready made one is the real thing 
that should be debated.

Julo

Nicolas Williams <[email-masked]> 
Sent by: [email-masked]
12/12/2003 20:23

To
"Noveck, Dave" <[email-masked]>
cc
[email-masked]
Subject
Re: [nfsv4] Global namespace for v4.1?

On Fri, Dec 12, 2003 at 10:13:56AM -0800, Noveck, Dave wrote:
> > Note that the MOVED error should be returned for any attempt to do
> > anything with the "ontap" directory component of that example path,
> > including crossing it in a LOOKUP.
> > 
> > And the answer to the "what filesystem" question is this: that which 
you
> > find by looking up the "rootpath" of an fs_location4 against an
> > fs_location4 server (and you can find the fs_id then too).
> 
> Huh?  rootpath is the path on the destination server but that doesn't
> tell you the fs on the original server that is replaced.  And fsid is 
> of no significance.  I don't care what the fsid is at that point
> (and I assume it might be different from the one on the source).  The
> only reason I can see for needing the fsid is to see the boundaries of
> fs's, and so for that I have to know what the boundaries fo the fs are
> on the original server, not the destination server.

The MOVED error is certainly an indication of an fs boundary on the
server that returns it.

> > > It may be that context (e.g. /nfs/netapp/src doesn't give you MOVED 
while
> > > /nfs/netapp/src/ontap) gives you enough to figure out the boundaries 
and 
> > > there is also the possiblity that fs_root in fs_locations may help 
here.
> 
> > I believe fs_locations4 tells the client what it needs to know: the
> > names of other servers to go to and the server-side paths ('rootpath')
> > to look up at each to get the FH for the directory/file covering the
> > referral trigger path.
> 
> I'm not sure what you mean by the referral/trigger path.  From my point
> of view, the critical thing is that it is an fs that moves and the 
> important thing for the client is to know the set of objects that have
> been relocated (i.e. which ones belong to the fs).

> > I'm not sure what fs_root is all about, actually -- but rootpath sure
> > looks useful.
> 
> Useful?  It's essential.  You have to be able to find the fs on the
> destination server. 

Ok, I know what's going on: I'm thinking of MOVED/fs_locations as a
mechanism for implementing referrals, which we need in order to
implement a global a namespace, but it is also intended for indicating
that a filesystem really moved while the client was using it.

So yes, fs_root may be essential for the case where a filesystem
actually moved, but it's redundant where MOVED/fs_locations is used
purely as a referral mechanism.

> > IMO fs_root is redundant - the client should already be able to
> > reconstruct the full server-side path that elicits the MOVED error
> > anyways 
> 
> If I do a READ using a fh I have and I get MOVED, then I may know the
> path of the file I opened, but it isn't necessarily the name of the
> file now.  So I would think of the basic model of migration being 
> fs-based in that I know all of the fh's associated with a given fs
> and look for them on a different server.  In some cases I may have 
> the name, or because of volatile file handles be forced to use a 
> best-guess, but, the first and most desirable thing is that you 
> be able to things transparently without oh-by-the-way-that-file-you-
> had-open-might-be-a-different-file-or-may-not-exist-live-with-it
> kind of stuff.

I assume FHs are to be preserved across migration, yes?

> > Proxy forwarding of client's requests to other servers won't work 
unless
> > the proxy has full rights to impersonate any users to the real server,
> > because the client won't be using the right GSS-API acceptor principal
> > name for the real server when talking to the proxy.  I think this 
means
> > that proxy forwarding for dumb clients will not be generally useful.
> 
> The client is thinks he is talking to a given server and to him it is 
the
> real server.  That server's job is to effect the client's wishes.  How 
he
> does that is up to him.  I gues he would be able to terminate GSS stuff 
> and make, for example, auth-sys requests of the real/ultimate server or
> have some sort of private protocol to support this function.  What am I 
> missing?

Nothing.  That's pretty much what I said -- the proxy would have to be
able to use AUTH_SYS to talk to the real server.  Of course, there is
the problem here in that AUTH_SYS is limited to 16 (17) groups, a
restriction that does not apply with RPCSEC_GSS.

Cheers,

Nico
-- 

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 13 Jan 2004 09:46:57 -0600

> might not see some parts of the structure).

To some extent you're quite right.

I've already pointed out more than once that there is a security problem
at the very least with finding namespace roots in that it's not enough
to mutually authenticate a client and server principal to each other -
the client principal MUST also _authorize_ the server principal to
provide the domain-wide service that it provides (that is, the namespace
root).

It probably will not be hard to make sure that clients do authorize root
servers, but beyond the namespace roots they'll have to rely on the root
servers to issue referrals only to trust-worthy file servers.

This will be the biggest stumbling block here, but it isn't that big,
and the way many folk implement LDAP simply having a client-side
automounter won't always suffice.

> MOVED is a good mechanism when fss have really moved (like in load 

I also think it's fine for referrals and building the namespace; but we
must solve the server authorization problem described above.

> whethere to build one in NFS or use a ready made one is the real thing 

That and the directory modelling of the namespace configuration data.

Nico
--