Re: [nfsv4] [FedFS] Root fileset questions

[Nicolas Williams <[e-mail]>]

On Thu, Dec 10, 2009 at 11:22:57AM -0500, James Lentini wrote:
> On Wed, 9 Dec 2009, [e-mail] wrote:
> > R15(b) also says that it should be possible for the a fileserver to locate
> > an NSDB that stores the layout of a root fileset.
> > 
> > I can’t remember where it is specified but the root fileset can contain only
> > directories and junctions.   
> 
> This was the consensus in our discussions on the topic. As I 
> mentioned, a formal specification of the root fileset has not been 
> proposed yet.

A limit on root filesets to directories and junctions does follow if the
contents of a root fileset is published in the NSDB (which might publish
only junctions, with all directories down from / being implied).

This also implies limitations on access controls for root fileset
contents.

> > (1) How does the file server know which NSDB to query to find out the
> > contents of the root fileset for a given namespace?     Doesn’t it need a
> > special ‘root junction’ that identifies the authoritative NSDB for the root
> > fileset for the namespace?

> Again, there isn't a definitive root fileset specification, so it 
> could be defined to work in many different ways. 

Indeed.

> I'm sure that there are other options as well.

It could be configured locally, or published in DNS (e.g., via a TXT RR).

> > That, and file server rendering the root
> > fileset to clients, leads to the question – how do replica NSDB's and/or
> > file servers that want to render the root fileset get updates?    The
> > fedfs-rootfileset draft that Renu circulated back in Sep. '08 says that this
> > was discussed but no conclusion reached (thanks for digging that out for me
> > James).   Seem like we need to come to a conclusion on this.

For root filesets consisting of junctions published in an NSDB the
servers would have to know to periodically search for new/deleted/
renamed junctions.  IIRC there's a way to get update notifications from
LDAP as well, but I suspect that periodic lookups will be the simplest
update method.

> > (4) What is the authentication model for access to the contents of the root
> > file set?  AUTH_NONE, AUTH_SYS?   I think this is the question that came up
> > recently and started me looking into all this.
> > 
> > (5) What is the security model within the root file set?  Completely open? 
> >  Un-modifiable mode bits and ACLs that are open (read-only) to all?
> 
> Security is another area that would need to be well defined in a root 
> fileset specification. We've discussed this topic in the past, but I 
> don't remember coming to any conclusions.

If root fileset contents is to be replicated we must either:

a) Not specify how to replicate it, potentially leading to non-
   heterogeneous root deployments; sadness would ensue, but we'd live;

b) Specify a replication protocol; this could get hairy;

c) Specify a simplified replication protocol (e.g., one master sending
   out tarballs);

d) Simplify the root fileset so much that publishing its contents via
   LDAP, where replication is already provided by existing off-the-shelf
   components, is simple and realistic;

   (Note that for LDAP there's going to be homogeneous NSDB deployments.
   So, (d) is not really a solution to the homogeneity problem in (a).)

All of these options have downsides.  We needn't do anything for (a) --
it's the simplest solution.  (b) is the best approach, but also utterly
not realistic.  (c) strikes me as a good possibility, but only if
there's a realistic chance that we could reach consensus on an archive
format that gives us everything that we need (files, directories,
junctions, including ACLs).  (d) strikes me as a good possibility, but
with poorer security semantics than (c).

Back to security: (d) pretty much implies that everything is wide open
for read and lookup access in the root fileset, which answers (5).  That
answer also answers (4): AUTH_NONE is sufficient.  To do better than
that with (d) would nullify the advantages of (d).

Nico
--