NFSv4.1 SACL attribute and AUDIT ACE: what's required?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

NFSv4.1 SACL attribute and AUDIT ACE: what's required?

Mike Kupfer-4
I'm trying to make sense of the final paragraph in Section 6.2.1.2 of
RFC 5661, which reads

    Support for any of the ACL attributes is optional (albeit
    RECOMMENDED).  However, a server that supports either of the new
    ACL attributes (dacl or sacl) MUST allow use of the new ACL
    attributes to access all of the ACE types that it supports.  In
    other words, if such a server supports ALLOW or DENY ACEs, then it
    MUST support the dacl attribute, and if it supports AUDIT or ALARM
    ACEs, then it MUST support the sacl attribute.

IIUC, this is forbidding a situation where (for example) the server
lists support for the dacl attribute and AUDIT ACEs but not support
for the sacl attribute.

If the server lists support for neither the dacl or sacl attributes,
it can still support AUDIT ACEs via the acl attribute.

Am I reading that correctly?

thanks,
mike

_______________________________________________
nfsv4 mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/nfsv4
Reply | Threaded
Open this post in threaded view
|

Re: NFSv4.1 SACL attribute and AUDIT ACE: what's required?

David Noveck
> I'm trying to make sense of the final paragraph in Section 6.2.1.2 of
> RFC 5661, 

Good luck with that.

> which reads

>      Support for any of the ACL attributes is optional (albeit
>     RECOMMENDED).  

It is hard to figure out since, in one paragraph, these attributes are optional, RECOMMENDED and (sometimes) REQUIRED. 
  • are (lower-case) "optional" at the start of the first sentence
  • are then "RECOMMENDED" at the end of the sentence, although this term is not in line with RFC2119.  (this sort of disparity recognized RFC7530, but still in RFC5661)
  • By the end of the paragraph. "MUST" is being used.

> However, a server that supports either of the new
>   ACL attributes (dacl or sacl) MUST allow use of the new ACL
>   attributes to access all of the ACE types that it supports.  

As the sentence is written, both of these attributes are OPTIONAL, but,
when you support one of them, the supported ACEs for those attributes
must include all the ACEs you support.  Essentially, this says that if you support
sacl and dacl, they must be the same.  I don't think that's the intention, though.
I think this sentence is just a mistake.

Perhaps the intention was to say that these attributes, when implemented,should 
support the ACE types that each of the attibutes were designed/intended to support,
if the server supports them at all.

>  In
>   other words, if such a server supports ALLOW or DENY ACEs, then it
>   MUST support the dacl attribute, 

This is essentially saying that if you support the acl attribute you have to support
dacl.  I don''t know if that is the intention.

> and if it supports AUDIT or ALARM
>   ACEs, then it MUST support the sacl attribute.



> IIUC, this is forbidding a situation where (for example) the server
> lists support for the dacl attribute and AUDIT ACEs but not support
> for the sacl attribute.

As I read it, support for dacl is irrelevant. I think it is saying that if
you support AUDIT ACE's you must be able to set them using the sacl attribute.  

> If the server lists support for neither the dacl or sacl attributes,
> it can still support AUDIT ACEs via the acl attribute.

I think that is sensible but it doesn't seem to be what the spec says.

On Fri, Jun 16, 2017 at 2:00 PM, Mike Kupfer <[hidden email]> wrote:
I'm trying to make sense of the final paragraph in Section 6.2.1.2 of
RFC 5661, which reads

   Support for any of the ACL attributes is optional (albeit
   RECOMMENDED).  However, a server that supports either of the new
   ACL attributes (dacl or sacl) MUST allow use of the new ACL
   attributes to access all of the ACE types that it supports.  In
   other words, if such a server supports ALLOW or DENY ACEs, then it
   MUST support the dacl attribute, and if it supports AUDIT or ALARM
   ACEs, then it MUST support the sacl attribute.

IIUC, this is forbidding a situation where (for example) the server
lists support for the dacl attribute and AUDIT ACEs but not support
for the sacl attribute.

If the server lists support for neither the dacl or sacl attributes,
it can still support AUDIT ACEs via the acl attribute.

Am I reading that correctly?

thanks,
mike

_______________________________________________
nfsv4 mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/nfsv4


_______________________________________________
nfsv4 mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/nfsv4
Reply | Threaded
Open this post in threaded view
|

Re: NFSv4.1 SACL attribute and AUDIT ACE: what's required?

Mike Kupfer-4
On 06/16/17 11:39, David Noveck wrote:

 >>   However, a server that supports either of the new
 >>   ACL attributes (dacl or sacl) MUST allow use of the new ACL
 >>   attributes to access all of the ACE types that it supports.
[...]
 > Perhaps the intention was to say that these attributes, when
 > implemented,should support the ACE types that each of the attributes
 > were designed/intended to support, if the server supports them at
 > all.

That was more or less my interpretation.

 >>   In other words, if such a server supports ALLOW or DENY ACEs,
 >>   then it MUST support the dacl attribute,
 >
 > This is essentially saying that if you support the acl attribute you
 > have to support dacl.  I don't know if that is the intention.

But there's that qualifier: "such a server".  I think that refers to
servers that support either dacl or sacl.  So if the server supports
acl, but not dacl or sacl, only the first sentence of the paragraph is
relevant.

    Support for any of the ACL attributes is optional (albeit
    RECOMMENDED).

The rest of the paragraph is moot.

mike

_______________________________________________
nfsv4 mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/nfsv4