Manoj Naik | 21 Jul 21:15 2014
Picon

Re: Fw: New Version Notification for draft-naik-nfsv4-xattrs-00.txt

Tom,

Responses inline based on the new draft we just submitted.

Manoj.

> From: "Haynes, Tom" <Tom.Haynes <at> netapp.com>
> To: Manoj Naik/Almaden/IBM <at> IBMUS, "nfsv4 <at> ietf.org" <nfsv4 <at> ietf.org>,
> Date: 03/04/2014 03:58 PM
> Subject: Re: [nfsv4] Fw: New Version Notification for draft-naik-
> nfsv4-xattrs-00.txt
> Sent by: "nfsv4" <nfsv4-bounces <at> ietf.org>
>
> Hi Manoj,
>
> Please find enclosed my review of your draft.

> 1) S1:
>
> A lot of claims of wide spread use of xattrs with no citations.
>
> 2) S1:
>
> Use case seems to be that it exists, so lets put it on the wire.

I have added a few more use cases. While there are quite a few applications that use xattrs where the underlying file system supports them, I found it was near impossible to find public citations for them. If anybody has references that can be documented, I would be glad to include them.

>
> 3) S1:
>
> What is the difference between xattrs and forks?

There is no explicit reference to the term "fork", which have varying implementations. Did you think we should bring out specific differences? The Solaris forks resemble the named attributes of NFSv4 closely, and the section on named attributes in the draft brings out the differences with xattrs.

>
> 4) S2:
>
> Please call out in stronger terms why we do only want to allow
> user-managed metadata only to prevent the development of
> non-interoperable implementations. I would actually think that
> the reverse is true.
>
> I.e., Labeled NFS object labels can be implemented as "security"
> xattrs. By having a well defined set of xattr names, it would
> promote interoperable implementations of seLinux.
>
> I'd like to see called out that the non-interoperable implementations
> here means that the xattrs are only utilized by the client and not
> the server. I.e., I do not want the xattr implementation to become
> a backdoor to driving new functionality into someone's server.
>
> And while that would appear to contradict my earlier statement
> about seLinux, the server would be enforcing the object label
> as it retrieved it from the sec_label attribute.
>
> I'd also like to see how this can be enforced at the protocol level?

Paragraphs 2 and 3 of Section 3 expands on this a bit in the new draft. Neither the client nor the server can interpret xattrs - only the applications can manipulate them (and the backend file system store them). The draft leaves open the option of using specific names to represent well-defined xattrs (such as seLinux) in a future document.

>
> 5) S3
>
>    Subsequently, xattrs presumably have size
>    limits ranging from a few bytes to several kilobytes, although this
>    is not universally defined.
>
> Are you going to define a limit for NFSv4?
>
> Are there limits on the size of the name?
>
> Is the name going to ASCII or UTF-8?
>
> Are there limits to the number of xattrs that can be associated with a fie system object?
> I.e., while a single xattr may be atomic, the collection of them may not.
>
> I see you develop this a bit in S4, but the reasons for why there are
> limits should be discussed here.

Section 5.1.1 and 5.1.2 now covers this. There is no limit on the size or number of xattrs as long as the request to get/set them can fit in a single RPC. This is similar to what is implicitly accepted for other file attributes such as ACLs - NFS4ERR_REQ_TOO_BIG is used to indicate an error.

>
> 6) S4
>
>    A client may ask for any of these attributes to be returned by
>    setting a bit in the GETATTR request but MUST handle the case where
>    the server does not return them.  A client may ask for the set of
>    attributes the server supports and SHOULD NOT request attributes the
>    server does not support.
>
> What is the server supposed to do if the client asks for xattrs and
> it does not support them?
>
> Also, this is GETATTR, should it not be GETXATTR or whatever you are
> going to call it?

Fixed.

>
> 7) S4
>
> 4.2.1  Attribute 82: xattr_support
>
>    TRUE, if the object's file system supports extended attributes.
>
> 4.2.2  Attribute 83: maxxattrsize
>  
>    Maximum size in bytes of all the extended attributes per object that
>    the object's file system supports.
>
> Do we need both? If maxxattrsize == 0, it indicates that there is no support
> for extended attributes.
>
> If we need both, what is the defined reaction to these value(s) (including
> xattrsize) being 0?

Fixed - xattr_support removed.

>
> 8) S4.2.2
>
> Are there any requirements that the xattr operations be atomic with any
> other operations inside the same compound?

No, in fact there is no requirement that setting multiple xattrs in the same SETXATTR is atomic either. See Section 5.2.4.3.

>
> 9) S4.2.4
>
>    Although the client can
>    get and set xattrs, the server is responsible for using the xattrs
>    for its own purposes.
>
> Again, I'd argue that the server cannot use the xattrs.

Yes, fixed.

>
> 10) S4.2.4
>
>    For SETATTR operation, if the
>    associated xattrvalue4 has a length of zero, the corresponding xattr
>    is to be deleted, if it exists.
>
> Where was xattrvalue4 defined?
>
> Wait, I see it after this. You might want to define that data structure first.

Fixed.

>
> 11) S4.2.4
>
>    Specific names of attributes will not
>    be controlled by this document or other IETF Standards Track
>    documents.
>
> Perhaps we can limit this to the "user" namespace and leave the
> decision of other name spaces to later documents.

Fixed.

>
> 12) S4.2.4
>
>         The NFS xattr structure is defined as follows:
>
>         typedef utf8str_cis         xattrname4;
>         typedef opaque                xattrvalue4<>;
>
>         struct xattr4 {
>                 xattrname4     xa_name;
>                 xattrvalue4    xa_value;
>         };
>
> Do maxxattrsize and xattrsize apply to just the xa_value or to combination
> of xa_value and xa_name?

Combination, now mentioned in Section 5.2.1.

>
> 13) S4.2.5
>
> How is the name space encoded inside the xattrname4?

As stated earlier, this draft does not impose restrictions on the xattr name - encoding namespace or defining specific names is left for a future document.

>
> 14) S4.2.5
>
>    The xattrnames is similar to xattrs attribute, except that it only
>    returns the names of the xattrs for the file system object without
>    the values. Each xattr is a tuple of the form (name, value).
>    xattrname4 is a UTF-8 string denoting the xattr name, xattrvalue4 is
>    a variable length string that identifies the values of a specified
>    xattr. The NFS client or server must not interpret the value.
>
> The last two sentences belong before this section. I.e., both
> xattrname4 and xattrvalue4 are also applicable to S4.2.4.

No longer required with the new operations.

>
> 15) S4.3
>
> xattrnames is basically a directory read. Do you need an ACE4 to control that?

The two ACE access mask attributes control permissions to GETXATTR/SETXATTR in the new draft.

>
> 16) Normative references are [RFC5661] and informative ones are [1].
>
> Please make consistent.
>
> Also, [KEYWORDS] should be [RFC2119].

Fixed.

>
> 17) Overall
>
> If xattrs are allowed to be run on the server, how do they interact with pNFS?
>
> Is the interpretation only to be on the MDS? Or do the DSes have an impact?

Added a section on pNFS considerations.

>
> How do xattrs interact with seLinux? I.e., once we get this in NFSv4.x, can
> the object label specify what subject labels are authorized to read/write/list the xattrs?

This draft does not limit on specify the names (or namespace) for xattrs. Perhaps in a future document.

>
> Finally, based on my experience with Labeled NFS, it might be better for you
> to split off the requirements and the implementation. There were much better
> use cases for Labeled NFS, but it still dragged on until we got the requirements
> gathered in a new document.

We see GETXATTR/SETXATTR as a fairly small extension to the protocol (in the same vein as READ_PLUS/WRITE_PLUS), that having requirements in a separate document may not have enough content and be warranted. The prevalence of xattr support in file systems is well-established, and despite the absence of a standard, their definition and operations are fairly consistent across platforms. Section 5.2 captures the requirements through the new operations.

>
> Tom
>
> From: Manoj Naik <mnaik <at> us.ibm.com>
> Date: Friday, February 7, 2014 at 8:38 AM
> To: "nfsv4 <at> ietf.org" <nfsv4 <at> ietf.org>
> Subject: [nfsv4] Fw: New Version Notification for draft-naik-nfsv4-
> xattrs-00.txt
>
> I have just submitted a draft proposal to support extended
> attributes in NFS. We've tried to include most of the views
> expressed on the mailing list in the past on this topic, and hoping
> the discussion can continue here, at Connectathon and at London.
>
> This first draft extends the existing attribute bitmap to include
> xattrs. This is easier to define and implement, but does not allow
> some operations like reading or writing individual xattrs.
>
> Other options mentioned (but not detailed) are:
> - define new operations - such as GETXATTR and SETXATTR - solely for
> xattrs. Cleaner, but has some consistency issues with GETATTR/SETATTR  
> with respect to attribute caching semantics.
> - define new operations - such as GETATTR_PLUS and SETATTR_PLUS
> (similar to extensions to READ/WRITE proposed for 4.2) - that
> support all the features of GETATTR/SETATTR, but include extensions
> to fully support xattrs.
>
> Please provide feedback.
>
> Manoj Naik
> IBM Almaden
>
>
> internet-drafts <at> ietf.org wrote on 02/07/2014 12:16:01 AM:
>
> > From: internet-drafts <at> ietf.org
> > To: mnaik <at> us.ibm.com, eshel <at> us.ibm.com
> > Date: 02/07/2014 12:16 AM
> > Subject: New Version Notification for draft-naik-nfsv4-xattrs-00.txt
> >
> >
> > A new version of I-D, draft-naik-nfsv4-xattrs-00.txt
> > has been successfully submitted by Manoj Naik and posted to the
> > IETF repository.
> >
> > Name:      draft-naik-nfsv4-xattrs
> > Revision:   00
> > Title:      Support for File System Extended Attributes in NFSv4
> > Document date:   2014-02-06
> > Group:      Individual Submission
> > Pages:      10
> > URL:            http://www.ietf.org/internet-drafts/draft-naik-
> > nfsv4-xattrs-00.txt
> > Status:         https://datatracker.ietf.org/doc/draft-naik-nfsv4-xattrs/
> > Htmlized:       http://tools.ietf.org/html/draft-naik-nfsv4-xattrs-00
> >
> >
> > Abstract:
> >    This document proposes extensions to existing NFSv4 operations to
> >    allow file extended attributes (here forth also referred to as
> >    xattrs) to be manipulated in the protocol. An xattr is a file system
> >    feature that allows opaque metadata, not interpreted by the file
> >    system, to be associated with files and directories and are supported
> >    by many modern file systems. New file attributes are proposed to
> >    allow clients to query the server for xattr support, and get and set
> >    xattrs on file system objects.
> >
> >
> >                                                                            
> >
> >
> > Please note that it may take a couple of minutes from the time of submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > The IETF Secretariat
> > [attachment "draft-naik-nfsv4-xattrs-00.txt" deleted by Marc
> Eshel/Almaden/IBM] _______________________________________________
> nfsv4 mailing list
> nfsv4 <at> ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
Manoj Naik | 21 Jul 21:13 2014
Picon

Fw: New Version Notification for draft-naik-nfsv4-xattrs-01.txt

I've submitted an update to the xattr draft that defines new operations, GETXATTR and SETXATTR, to manage extended attributes. Please provide feedback.

Regards,
Manoj Naik
IBM Almaden

----- Forwarded by mnaik <at> us.ibm.com on 07/21/2014 11:07 AM -----

internet-drafts <at> ietf.org wrote on 07/20/2014 09:53:07 PM:

> From: internet-drafts <at> ietf.org
> To: mnaik <at> us.ibm.com, eshel <at> us.ibm.com
> Date: 07/20/2014 09:53 PM
> Subject: New Version Notification for draft-naik-nfsv4-xattrs-01.txt
>
>
> A new version of I-D, draft-naik-nfsv4-xattrs-01.txt
> has been successfully submitted by Manoj Naik and posted to the
> IETF repository.
>
> Name:      draft-naik-nfsv4-xattrs
> Revision:   01
> Title:      Support for File System Extended Attributes in NFSv4
> Document date:   2014-07-18
> Group:      Individual Submission
> Pages:      16
> URL:            http://www.ietf.org/internet-drafts/draft-naik-
> nfsv4-xattrs-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-naik-nfsv4-xattrs/
> Htmlized:       http://tools.ietf.org/html/draft-naik-nfsv4-xattrs-01
> Diff:           http://www.ietf.org/rfcdiff?url2=draft-naik-nfsv4-xattrs-01
>
> Abstract:
>    This document proposes extensions to existing NFSv4 operations to
>    allow file extended attributes (here forth also referred to as
>    xattrs) to be manipulated in the protocol. An xattr is a file system
>    feature that allows opaque metadata, not interpreted by the file
>    system, to be associated with files and directories and are supported
>    by many modern file systems. New file attributes are proposed to
>    allow clients to query the server for xattr support, and new
>    operations to get and set xattrs on file system objects.
>
>
>                                                                              
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
Tom Haynes | 14 Jul 23:03 2014

RPCSEC_GSSv3/LNFS and NFSv4.2 draft status

Thanks for the edits Andy, I’ve pushed them out.

Having said that, I’m about to nuke the wording on delegations with LNFS. A little birdie
(okay, Trond) pointed out a serious issue with that approach:

> The file I/O operations are the only ones that take delegation
> stateids; the rest can't be protected this way.
> Furthermore, a bunch of operations actually require you to _discard_
> the delegation before execution (e.g. unlink(), rename(), ...) so
> cannot even be protected by implication.

I’m not going to advocate the CB method nor the change_sec_label.

Instead, I’m going to point out the issue, that we don’t have enough data
on how often a label changes (we suspect it is very rare), etc. The client
can grab a new copy of the attribute if it cares. But any other approach
needs to wait until we get implementation experience, which means 4.3.
_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

andros | 14 Jul 21:06 2014
Picon

[Version 2 PATCH 1/1] Destroy copy_confirm_auth handle when copy_from_auth destroyed

From: Andy Adamson <andros <at> andros-16g.gateway.2wire.net>

Signed-off-by: Andy Adamson <andros <at> netapp.com>
---
 nfsv42_middle_copy.xml | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/nfsv42_middle_copy.xml b/nfsv42_middle_copy.xml
index 928758d..844e205 100644
--- a/nfsv42_middle_copy.xml
+++ b/nfsv42_middle_copy.xml
 <at>  <at>  -1058,6 +1058,15  <at>  <at> 
           </t>

           <t>
+           The copy_confirm_auth RPCSEC_GSS3 handle is associated with a
+           copy_from_auth RPCSEC_GSS3 handle on the source server via
+           the shared secret and MUST be locally destroyed
+           (there is no RPCSEC_GSS3_DESTROY as the source server is
+           not the initiator)
+           when the copy_from_auth RPCSEC_GSSv3 handle is destroyed.
+          </t>
+
+          <t>
             If the client sends an OFFLOAD_CANCEL to the source server to
             rescind the destination server's synchronous copy privilege, it
             uses the privileged "copy_from_auth" RPCSEC_GSSv3 handle and the
--

-- 
1.8.5.2 (Apple Git-48)

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

internet-drafts | 14 Jul 19:33 2014
Picon

I-D Action: draft-ietf-nfsv4-layout-types-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Network File System Version 4 Working Group of the IETF.

        Title           : Requirements for pNFS Layout Types
        Author          : Thomas Haynes
	Filename        : draft-ietf-nfsv4-layout-types-00.txt
	Pages           : 11
	Date            : 2014-05-16

Abstract:
   This document provides help in distinguishing between the
   requirements for Network File System (NFS) version 4.1's Parallel NFS
   (pNFS) and those those specifically directed to the pNFS File Layout.
   The lack of a clear separation between the two set of requirements
   has been troublesome for those specifying and evaluating new Layout
   Types.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-layout-types/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-nfsv4-layout-types-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

internet-drafts | 14 Jul 19:32 2014
Picon

I-D Action: draft-ietf-nfsv4-rpcsecgssv3-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Network File System Version 4 Working Group of the IETF.

        Title           : Remote Procedure Call (RPC) Security Version 3
        Authors         : Thomas Haynes
                          Nico Williams
	Filename        : draft-ietf-nfsv4-rpcsecgssv3-00.txt
	Pages           : 23
	Date            : 2011-05-23

Abstract:
   This document specifies version 3 of the Remote Procedure Call (RPC)
   security protocol (RPCSEC_GSS).  This protocol provides for: compound
   authentication of client hosts and users to server (constructed by
   generic composition), channel binding, security label assertions for
   multi-level and type enforcement, privilege assertions and identity
   assertions.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpcsecgssv3/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-nfsv4-rpcsecgssv3-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

Spencer Shepler | 11 Jul 19:41 2014
Picon

Agenda for Toronto

 

Let me know if updates are needed…

 

 

NFSv4 Working Group

Toronto

Time: 9-11:30 AM

Room: Salon A

Date: July 25, 2014

[version 0.1]

 

Note Well

 

Agenda Bashing

 

NFSv4.2 Updates and Issues (Haynes)

 

Considerations for a New pNFS Layout Type (Haynes)

draft-haynes-nfsv4-layout-types-02

 

Parallel NFS (pNFS) Flexible Files Layout (Haynes)

draft-bhalevy-nfsv4-flex-files-02

 

RPCSEC_GSSv3 I-D Update (Adamson)

draft-ietf-nfsv4-rpcsec-gssv3

 

Multi Domain FedFS (Adamson)

draft-adamson-nfsv4-multi-domain-federated-fs-reqs

 

Inter SSC Copy Demo (Adamson)

 

Xattr Protocol Extensions (Eshel)

 

pNFS Metadata Striping (Benjamin)

     draft-mbenjamin-nfsv4-pnfs-metastripe

 

 

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
Chuck Lever | 8 Jul 17:26 2014
Picon

Fwd: Expiration impending: <draft-cel-nfsv4-federated-fs-security-addendum-00.txt>


Begin forwarded message:

> From: IETF Secretariat <ietf-secretariat-reply <at> ietf.org>
> Subject: Expiration impending: <draft-cel-nfsv4-federated-fs-security-addendum-00.txt>
> Date: July 7, 2014 at 7:42:10 AM EDT
> To: "Chuck Lever" <chuck.lever <at> oracle.com>
> 
> The following draft will expire soon:
> 
> Name:     draft-cel-nfsv4-federated-fs-security-addendum
> Title:    Federated Filesystem Security Addendum
> State:    I-D Exists
> Expires:  2014-07-19 (in 1 week, 4 days)

I have an update to this document, but according to this page:

  http://datatracker.ietf.org/submit/

I am not allowed to submit it until 07-21, two days after the
current revision expires.

Is there a grace period?

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

internet-drafts | 7 Jul 15:16 2014
Picon

I-D Action: draft-ietf-nfsv4-rpcsec-gssv3-08.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Network File System Version 4 Working Group of the IETF.

        Title           : Remote Procedure Call (RPC) Security Version 3
        Authors         : William A. (Andy) Adamson
                          Nico Williams
	Filename        : draft-ietf-nfsv4-rpcsec-gssv3-08.txt
	Pages           : 20
	Date            : 2014-06-27

Abstract:
   This document specifies version 3 of the Remote Procedure Call (RPC)
   security protocol (RPCSEC_GSS).  This protocol provides for multi-
   principal authentication of client hosts and user principals to
   server (constructed by generic composition), security label
   assertions for multi-level and type enforcement, structured privilege
   assertions, and channel bindings.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpcsec-gssv3/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-nfsv4-rpcsec-gssv3-08

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-nfsv4-rpcsec-gssv3-08

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

Tom Haynes | 30 Jun 19:33 2014

Re: [PATCH 2/2] Destroy copy_confirm_auth handle when copy_from_auth destroyed


On Jun 27, 2014, at 10:49 AM, andros <at> netapp.com wrote:

> From: Andy Adamson <andros <at> andros-16g.gateway.2wire.net>
> 
> Signed-off-by: Andy Adamson <andros <at> netapp.com>
> ---
> nfsv42_middle_copy.xml | 8 ++++++++
> 1 file changed, 8 insertions(+)
> 
> diff --git a/nfsv42_middle_copy.xml b/nfsv42_middle_copy.xml
> index 928758d..6de7836 100644
> --- a/nfsv42_middle_copy.xml
> +++ b/nfsv42_middle_copy.xml
>  <at>  <at>  -1058,6 +1058,14  <at>  <at> 
>           </t>
> 
>           <t>
> +           The copy_confirm_auth RPCSEC_GSS3 handle is associated with a
> +           copy_from_auth RPCSEC_GSS3 handle on the source server via
> +           the shared secret and MUST be locally destroyed
> +           (no RPCSEC_GSS3_DESTROY as the source server is no the initator)

The second “no” is definitely a “not”.

Is the first as well?

Thanks.

> +           when the copy_from_auth RPCSEC_GSSv3 handle is destroyed.
> +          </t>
> +
> +          <t>
>             If the client sends an OFFLOAD_CANCEL to the source server to
>             rescind the destination server's synchronous copy privilege, it
>             uses the privileged "copy_from_auth" RPCSEC_GSSv3 handle and the
> -- 
> 1.8.5.2 (Apple Git-48)
> 

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

Adamson, Andy | 25 Jun 23:21 2014
Picon

Two methods of passing the NFSv4.2 LNFS subject label for Full Mode

I’m getting up to speed on the Full mode LNFS issues in NFSv4.2, and I see two ways to enable it.

Disclaimer: I am new to LNFS issues and MAC implementations and use, so I could easily be missing context.
Please inform me in detail if this is so :)

The tuple <subject label, object label, policy engine> provides MAC (Mandatory Access Control), a much
finer grained access control than traditional DAC (Discretionary Access Control) which uses UID/GID
and ACLs to determine access to a resource. MAC is enforced by the policy engine with subject and object as inputs.

Client guest-mode LNFS occurs when the subject label remains on the client, and the object label for a file
or directory is stored on the server. In this mode, the policy enforcement occurs only on the client which
retrieves the object label, and then sends both the subject and object labels to a client side policy
engine to determine access. This mode is completely described in
draft-ietf-nfsv4-minorversion2-27.txt (!!).

To enable full mode, where both the client and the server enforce policy, the subject label needs to be
forwarded to the server with each NFS request that the subject label applies to, so that the server can then
send the subject and object labels to it’s MAC policy engine.

The problem:
-----------
How to forward the subject label to the server so that it can also enforce MAC with the same subject/object as
the client.

I see two ways of looking at MAC info, each with a solution and a protocol impact.

1) The MAC subject is identity information.
---------------------------------------------
The caller is identified not only by the UID/GIDs (after mapping any GSS principal) but by a combination of
UID/GIDs and MAC subject e.g. the MAC subject forwarding belongs in the RPC layer.

draft-ietf-nfsv4-minorversion2-27.txt, as well as draft-ietf-nfsv4-rpcsec-gssv3-
08.txt look at MAC info as part of the identity of the caller, and via GSS3, place the communication of the
subject in the RPC layer.

There are a few GSS3 draft changes needed to complete this design, but the basic
 idea is that each subject is asserted in a GSS3 label assertion which means that a child gss3 context is
created that contains the subject, and both the client and the server store the subject info associated
with the new gss3 child handle
.  Each time that subject needs to be asserted across the nework, the associated
 gss3 context is used.Use GSS3 to transport MAC subject to server:
Pros:
        - Subject info transferred once in an RPCSEC_GSS3_CREATE label assertion
        - Use of gss3 child handle asserts subject
        - Once setup, no RPCSEC_GSS privacy or integrity requirements wRT label.
        - Destruction of gss3 child handle invalidates the subject on the server

Cons:
        - May not scale.  Given a bunch of subjects, a parent GSS context
        could be required to store a bunch of assertions.
        I don't don't have the experience to know if the are or will be a
        bunch of subjects being used between a client and a server.
        - Given a subject, the NFS client needs to decide
        which gss3 child context, or the parent context, to use. This could
        be messy WRT implementations which currently make this decision on a        per RPC credential basis (does this
mean a lot more RPC credentials?).

2) The MAC subject is like ACL information.
-------------------------------------------

The MAC subject is additional info beyond any ACL info associated with the
NFS file or directory and is independent of the callers identity. e.g. the
MAC subject forwarding belongs in the NFSv4.2 layer.

In this design, I create a new NFSv4.2 operation to hold a subject label, and perhaps a new attribute to query
a file systems LFS support (probably could just use sec_label).

This new operation would be placed directly after the SEQUENCE operation in all appropriate NFS requests,
and thus would be processed prior to any file access operation.

Use a new NFSv4.2 operation to transport the MAC subject to the server.

Pros:
        - No new storage requirements on the server
        - Scales to the number of subjects
        - Simplify draft-ietf-nfsv4-rpcsec-gssv3 (get rid of label assertions
        and RPCSEC_GSS_LIST.

Cons:
        - Requires GSS integrity or privacy on each NFS request.
        - Adds an operation to NFSv4.2

I'm willing to write up protocol changes for each idea, and/or gather responses and present them at IETF 90.

-->Andy

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4


Gmane