Re: [nfsv4] [LNFS] Updated draft

[Thomas Haynes <[e-mail]>]

On May 3, 2011, at 8:42 AM, sfaibish wrote:

> On Tue, 03 May 2011 04:36:45 -0400, Dave Quigley <[e-mail]> wrote:
> 
>> On 5/3/2011 12:57 AM, Thomas Haynes 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
> I assume that the virtualization usecases will be addressed (currently
> Section 9.2 looks a little too thin). For example it doesn't make any
> distinctions between on wire and on disk protection).


Please feel free to provide more text for this area.



> 
>>> 
>>> 2) The new callback, CB_LABEL_CHANGED
>>> 
>>> 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.
>> 
>> So in the LFS document that Jarrett and I wrote we reserved LFS 0 as
>> unused. I had originally argued that LFS 0  should be a null LFS where
>> it is completely opaque and you better be sure that everyone is speaking
>> the same language before you used it. Since you've come up with a
>> similar concept I'm wondering if this is a bettter use of LFS 0 than
>> reserving it. If we do define LFS 0 as being a sort of NULL label format
>> should that description go into the LFS document or should it be a
>> document referenced by the LFS document?
> No additional external documents please.


Right now this is kept in http://tools.ietf.org/html/draft-quigley-label-format-registry-01

I will pull this document into the current draft with the next revision.  (This is
actually one of the questions within the draft.)


> Neverthless I thought we discussed
> to use label 0 (or NULL) for dumb clients to which the server sent the support for
> LFS but client doesn't understand labels except is aware of server being capable.
> (I think me and David Black were looking at this).



I actually don't care what scheme gets used as 0. I'd like for us to define such
basic scenarios as the first values.

I don't see the need for a unique LFS in the above scenario. If the clients are
dumb, then that puts all decision making on the server. But the spec claims
that the NFS client and server does not make any decisions on MAC labels.
So we would need to define a security system to handle all of this. I think
that is out of scope for this draft.

I don't have the same issue for the smart client/label aware server because
we are not defining any security decision making. We are simply defining
additional transport semantics to allow the clients to react to a change in
the label.









> 
>> 
>> 
>>> 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.
>>> 
>>> 4) An example of how the new callback enables LFS 0 to work.
>>> 
>>> 5) DS to MDS label enforcement
>>> 
>>> NOTE: I was purposely vague on details here. In the last meeting,
>>> this area drew concern about how FILE, OBJECT, and BLOCK
>>> layouts work here. My claim is that they already work with DAC
>>> access checks and by piggybacking on top of that mechanism
>>> for each layout type, we can avoid layout type specific language.
>>> 
>>> 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.
>> 
>> The view I originally held for this was that when a smart server gets a
>> label from a client it would translate it from the client's DOI(meaning
>> LFS/PI combination) into its own local one and store the labels like
>> that. Because of this there is a translation that happens at the
>> boundaries between clients. We can discuss further where we think they
>> should be (I'm tempted to say at the server). This way a client really
> This is true/possible only for LFS aware servers. We need to ensure that
> "dumb" servers that support only the LFS attributes can still support
> different types of clients supporting different DOIs. The entire
> discussion is mostly for the LFS aware clients and servers and we
> need to be sure that unaware servers are supported.


I think this is a good observation, it has really made me think about our
model.

Some terms:

Dumb server - it neither stores nor transports labels
Label aware server - it stores and transports labels, but it does not act on them
Smart server - it stores, transports, and acts on labels.

What you are stating is that a label aware server needs to accept
more than LSF 0 from a client. It sounds attractive, but there are some
complications:

1) What happens when that server is upgraded to a smart server?

This one states that a smart server has to be able support multiple DOI
anywhere in the namespace. Or it has to be able to map all existing
FATTR4_SEC_LABEL attributes to values that it supports (which
is vague enough to allow a security system which understands
multiple DOI).

2) How do the  smart clients  determine what to do with an LFS (and/or DI)
that they know nothing about?

This one really implies to me we only want to support one LFS in
a label aware server, but that still does not work. The LFS would still
be 0, but each client would have to interpret the opaque label. We
could get labels that the client knows nothing about.


More on this below...


> 
>> only needs to know about its own DOI while the server needs to know how
>> to talk among multiple clients. However, and this is a big caveat here,
>> something may get lost in translation. You have to be conscious when
>> doing this that your translations are in fact not lossy otherwise you
>> could get a situation where the label you put on disk is not the one you
>> got back.
> I agree with this statement and we must prevent making this behavior
> responsibility of the server. This also means that the server is aware of
> all the LFS existing in all environments. How do you define this? Use a LSF
> database? And why is this a v4.2 protocol issue. How to manage different LSF.
> IMHO this is a server implementation detail. I would like to see as little as
> possible included in the 4.2. And yes this can be defined in a different
> document.


I agree that defining how a server support multiple LSFs is not in the scope
of this document. However, how the server reports such scenarios to the
client is very much in scope.

Some questions which we need to consider:

1) Can a file object have multiple labels, each of which is DOI dependent?

So far the answer is no, in that security system would have to do the mapping.

2) Can a directory object have multiple labels, each of which is DOI
dependent?

This one is more tricky as we have yet to flesh out what we are going to
do with directory objects. I.e., we disallow a client from reading a directory.

I think the answer is still no. We have to let the security system do the
mapping.

3) Which security system gets to do the mapping if the server supports both?
The one the client is using, as shown in the subject label, or the one shown
in the object label?

I think the answer is always the object label.

4) How do we handle an object label for which there is no security system?

I think this one is server dependent and outside of the scope of the document.



BTW - nothing we have put in place keeps a client from being able to
speak multiple DOIs. 


I think 99% of all deployments will be a single LFS and perhaps multiple DI.
I hope that anyone who deploys multiple LFS on a server does so with
subtrees and has no other mingling within a directory.

I think we either decide:

1) The first implementation of LNFS is only going to support one LFS on the
server. We will push off doing multiple ones until we have some implementation
experience.

BTW - are there any existing servers which support multiple LFS on local
filesystems.

2) We support multiple LFS on the server and provide a section which details
a best practices implementation guide.










> 
>> 
>> This method allows support for LFSs which implement similar models to
>> talk with each other.  For example, SELinux and FreeBSD MLS policy. Both
>> can implement DOE or DOD MLS labeling. There may be a situation where
>> you deem it acceptable for them to work on the same data set. However
>> this is where we get a lossy translation. A FreeBSD system can place a
>> label onto a file and the server will have to fill in the remaining
>> SELinux components when giving that label out to an SELinux client. We
>> have to make a decision as to whether it is up to the server to give out
>> default label values for a LFS or if its up to the client to fill in the
>> blanks.
> I vote for the server give out a default value (NULL) and the unaware client
> to use NULL to label new objects as recommended by the server.


If the client is unaware, how does it set labels?

I think the default label generation should be security system dependent. You
can either record NULL, in which case the system needs to map that to a default,
or you can set the label.

The benefit of setting it is in scenarios where we allow multiple LFS
on the same server. A NULL can be interpreted differently, whereas
a set label has only one interpretation and it forces the server to
use the correct LFS to parse it.



> 
>> 
>> I think this is something that we need to discuss further.
> Agreed. This issue should be in the Agenda for the next meeting.
> 
>> 
>>> 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.
>>> _______________________________________________
>>> nfsv4 mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/nfsv4
>>> 
>> 
> 
> 
> 
> -- 
> Best Regards
> 
> Sorin Faibish
> Corporate Distinguished Engineer
> Unified Storage Division
>        EMC²
> where information lives
> 
> Phone: [phone]
> Cellphone: 617-510-0422
> Email : [e-mail]