[nfsv4] [LNFS] Meeting Notes for 05/12/2011

[Thomas Haynes <[e-mail]>]

Attendees
--------------

Tom Haynes (NetApp)
Dave Quigley 
Jarrett Lu (Oracle)
Peter Staubach (EMC)
David Black (EMC)
Sorin Faibish (EMC)
Trond Myklebust (NetApp)
Dave Noveck (EMC)
Jack Yap (EMC)
Nico Williams 

Agenda
-----------

+ IETF Note Well Agreement

+ Administrivia

This is the new conference number for all further meetings.

+ Multiple labels per object

We agreed that we will change the XDR to allow multiple labels.

Jarret pointed out that we use the term DOI incorrectly. Tom
responded that it is defined twice, one in the security context
and once as a data structure.

We need to straighten this out as our use of DOI will not
be understood outside of the our community.


+ Discovery of LFS supported by server

A better question might be whether the server or client is smart.

Dave N. suggested we use the EXCHANGE_ID to determine that.

Sorin detailed a label aware server that might want to reject requests
from dumb clients. Both David Q and Jarrett could not see the use cases.

This devolved into a discussion of whether or not a file has a default
label and how that gets constructed.

One point (by David Q) was whether a label aware server needed to
reject a file creation that did not set the label, which would basically
rule out all dumb clients. Tom pointed out this would violate the
property that label aware servers do not enforce.

David Q made a very good point in that if a server is label aware, then
that means it is a MAC system, and all objects in a MAC system need
to have a label.

Tom brought up upgrading existing systems.

We discussed where the line is for what we need to do and what the
security system needs to do.

A security system must create default labels for objects which do not
have a label. We do not mandate how or when that is done, that
is an implementation issue. So is whether or not the label is attached
to the file or derived again the next time it is needed.


+ Label aware server

postponed

+ LFS Registry

Tom will drop this from the next draft.

Where do PIs get documented?

In retrospect, we talked about two types of PIs:

1) Implementation wide

2) Site wide

In the first, every implementation of the LFS must understand the PI. And that needs
to be handled in the LFS spec.

In the second, it is much more dynamic and controlled by the site security admin.
Using your SMACK example, it could be a mapping of which ruleset to use. It
would be the responsibility of the admin to make sure there were no conflicts.

Not all LFSes would allow site wide configuration and it would be the responsibility
of the implementation to allow configuration and use of the PI.

David Q also brought up that PIs were optional for a LFS. We need to document
what the value will be if the PI is not used. I.e., reserve PI=0.

+ Namespace access

We are going to drop this section.

We talked about READDIR filtering.

The security system decides what gets reported (and how) for either READDIR or LOOKUP.

I.e., it can be silent or it can state no permission allowed.


+ CB_LABEL_CHANGED

We are taking Nico's proposed changes.

+ Label change algorithm

postponed

+ Interop Testing at the BAT

Tom - label aware server (NetApp)

David Q - not present, will send a VM seLinux - client and server (Linux)
will focus on a label aware client, not a server

Jack - label aware (EMC)

Tom took an AI to contact Rick Macklem to see if he can supply something.