Re: [nfsv4] [LNFS] Updated draft

[Thomas Haynes <[e-mail]>]

On May 3, 2011, at 10:44 AM, Nico Williams wrote:

> On Mon, May 2, 2011 at 11:57 PM, Thomas Haynes <[e-mail]> wrote:
>> I just pushed out a new version of the draft: draft-quigley-nfsv4-labeled-01
>> and it can be accessed via http://datatracker.ietf.org/doc/draft-quigley-nfsv4-labeled/
>> 
>> Since the first draft, I have added:
>> 
>> 1) The additional use cases provided by Kathleen Moriarty
>> 
>> 2) The new callback, CB_LABEL_CHANGED
> 
> Is this the only meta-data for which we'll ever want such a callback?

I think so. I'll take an AI to examine this.


> 
> If not I think a generic callback would be better.  The key is to
> distinguish critical from non-critical meta-data changes (which could
> be done via two sets of attrs, or a simple flag, for example).


Even if it is currently the only meta-data we want to support, it
might be a good idea to use your proposed extension to support
something we are not foreseeing.

What I like about this idea is that it only reports that something
has changed, but not how. The client still has to query the server
to determine the change. (Which is a requirement for this work.)


> 
>> 3) A description of LFS 0, which is a simple security system for:
>> a) Debugging infrastructure
>> b) Only storing and returning the label. I.e., allowing smart
>> clients to work together.
>> 
>> NOTE: I chose LFS 0 because it defined a default security
>> system for LNFS aware servers and it allowed for debugging
>> of the transport code.
> 
> What would this LFS' properties be?  Suppose it grants access only
> when the subject label equals the object label...  but you'd be so
> close to Smack then!


A very good question, especially when combined with Sorin's
observation that  the smart clients probably want to store labels
with the DOI that they are using. I.e., if we ever upgrade a label
aware server to a smart server, we already have the labels correct.

I think what we might want to do is use LSF 0 on the ROOTFH to
indicate that the server is label aware and not smart.

PUTROOTFH, GETATTR {FATTR4_SEC_LABEL}

A LSF of 0 states the server is label aware.
Any other LSF states that the server is smart.

And it indicates that it is a dumb server by not setting the appropriate
bit.

And then I don't know what we want to do with properties inside
the rest of the filesystem. I think we only want to allow a NULL
label if the LFS is 0. If the smart clients have an implementation
that they want to remain private, they are free to use one of
the LSF marked for Private Use only in the registry. Otherwise,
they will use the LSF that they all understand.


> 
>> 6) A means for a client to discover the LFS supported by the server.
>> 
>> An interesting point here is that we have discussed the client and
>> server having different LFS, but we haven't discussed the server
>> supporting multiple LFS at the same time. I.e., we allow for the
>> server's security system to map from LFS A to LFS B, but we
>> do not explicitly state whether the server can support multiple
>> LFS in its namespace.
>> 
>> Do we want to consider such an extension? In my mind, the
>> difficulty is in the client being presented with a directory which
>> contains objects which are the root of different LFS models.
>> I.e., the whole security flavor approach we take for AUTH_SYS
>> and kerberized access.
> 
> What would the extension be like, OTW?


I'd like to hold off on that discussion until we cover the namespace
issues.


> 
> Anyways, servers can support multiple LFSes/DOIs, either by
> translation between them or by simply allowing it and applying the
> different rulesets as appropriate.  In the latter case users will, no
> doubt, prefer to segregate content by LFS...  In practice I don't
> really see this happening.
> 
> A much more interesting model would be one where each subject and
> object can have more than one label.  This could be a DTE label and an
> MLS label -- one to enforce domain-types, the other to enforce
> compartments and levels.  This could be a useful way to combine LFSes
> (all MAC policies being ANDed).  I'm not sure that there will be
> demand for this, but, incidentally,  RPCSEC_GSSv3 allows clients to
> assert more than one subject label...


I had just been reading the RPCSEC_GSSv3 spec on that matter.



>  Just to keep this option open
> I'd suggest that NFS allow more than one object label as well.


I think we should bring this up at the next meeting. I'd also like
to keep this option open.



> 
> Nico
> --
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4