[nfsv4] Comments for draft-rmacklem-nfsv4-posix-acls-02

[Pali Rohár <[e-mail]>]

Hello Rick,

As we were discussed off-list, I'm sending to this list my comments for
your draft-rmacklem-nfsv4-posix-acls-02 document. Quoted text is
verbatim copy from your document.

Your document describe POSIX ACL support only for NFS v4.2. The most
commonly used NFS4 version is 4.1 and it would stay for a longer time,
lot of enterprise NFS SW is being written as NFS3 + NFSv4.1 (no v4.2
support). So to make extension widely usable, it needs to be also for
NFS v4.1. Is there any reason why v4.1 is not included in your document?

> Therefore, a client MUST not set the low order 9 bits of mode via the
> mode or mode_set_masked attributes in the same SETATTR operation as
> one that sets the posix_access_acl and/or posix_default_acl proposed
> in this document. This is required because [RFC8881] does not specify
> an ordering for setting attributes in a SETATTR operation.

RFC 8881 in section "6.4.1. Setting the Mode and/or ACL Attributes"
describes the ordering of setting MODE, ACL attributes.

In section "6.4.1.3. Setting Both ACL and Mode" is covered any ACL
attribute with any MODE attribute:
"When setting both the mode (includes use of either the mode attribute
or the mode_set_masked attribute) and the acl or dacl attributes in the
same operation, the attributes MUST be applied in this order: mode (or
mode_set_masked), then ACL."

I think it would be better if your extension says that the new
POSIX_*_ACL attributes has to be handled as ACL attribute according to
RFC 8881 6.4.1.3. section. It would simplify MODE and ACL interop in
SETATTR operation.

> Therefore, to maintain compatible semantics with the POSIX draft, for
> NFSv4 operations that create new file objects (OPEN/OPEN4_CREATE,
> CREATE) in a directory that has a POSIX default ACL, the low order 9
> bits of the mode SHOULD be specified by either mode or mode_set_masked
> in the setable attributes for the operation.

RFC 8881 in section 6.2.5. specifies:
"The mode_set_masked attribute is only valid in a SETATTR operation. If
it is used in a CREATE or OPEN operation, the server MUST return
NFS4ERR_INVAL."

So when creating a new object "mode_set_masked", cannot be used. For
inheritance you need to use "mode_umask" attribute which is defined in
RFC 8275. This attribute already handles this POSIX inheritance issue
and I think it is required for proper POSIX ACL implementation.

> For a SETATTR, setting a zero length acl (for a file object with a
> true form ACL of ACL_MODEL_NFS4) ... will delete the true form ACL(s)
> from the file object and revert it to ACL_MODEL_NONE.

Why is this needed? Empty NFS4 ACL is same valid NFS4 ACL. If somebody
want to restrict access to some file then setting empty list of ACEs
which is zero-length acl. I think that ACL with no access should still
be in NFS4 model.

Comparing with Windows. On Windows (and in SMB protocol) there are two
different operations which can be done on object: Erasing DACL (by
setting it to NULL) and setting empty DACL (by setting empty list of
ACEs). Erasing is really erasing of the DACL in the storage (similar
like erasing POSIX ACL and reverting to mode_only) which has same effect
as ALLOW-EVERYONE-FULL-ACCESS. And setting empty list has effect of the
DENY-EVERYONE-FULL-ACCESS (as ACLs are default-DENY, there is no rule
which can grant some access).

As NFS4 does not have a way to set ACL to NULL, it has only the section
option and matches Windows behavior of empty-ACE-list as NFS4 is also
default-DENY.

> A server that is configured for a acl_trueform_scope other that
> ACL_SCOPE_FILE_OBJECT MUST not support the posix_default_acl and
> posix_access_acl unless the true form for the file system is
> ACL_MODEL_POSIX_DRAFT.

This is a restriction which basically means that no existing NFS4
server with native NFS4 ACL support can support "posix_access_acl".
In multiprotocol environment where is NFSv4.0 and NFSv4.1, the NFS4
server would have to provide server scope native NFS4 model (to support
NFSv4.1 as as your document is only for NFSv4.2) which implies that
server must not support POSIX ACL. And same applies in the multiprotocol
environment with NFS4 and SMB.

I think that this is too strict and what would happen is either that
this extension would not be implemented OR section option (which I think
everybody would do) is ignoring this restriction.

I guess that for compatibility with FreeBSD and Linux, servers would
implement it even on NFS4 server scope model.


And I have there two additional points without quoting your document.

1)

Your document does not describe what existing RFC 8881 acl and dacl
attributes should return when user sets new "posix_default_acl" or
"posix_access_acl" attribute. Also what should happen when another
client tries to change acl or dacl attribute when POSIX ACL is already
active.

If interop between mode, dacl and posix_default_acl, posix_access_acl
attributes is not explicitly defined in specification then every server
implementation will invent its own rules and it would just lead to the
mess in multiprotocol environment where clients would not be sure what
can happen. Like it is already with "mode" attribute in NFS v4.1 (see 2).

2)

Then there is a problem with "group" bits of "mode" attribute.
In RFC 8881 section 6.2.4 is written:

"Bits MODE4_RGRP, MODE4_WGRP, and MODE4_XGRP apply to principals
identified in the owner_group attribute but who are not identified in
the owner attribute."

And in section 6.3.2.1 is written:

"Some server implementations also add bits permitted to named users and
groups to the group bits (MODE4_RGRP, MODE4_WGRP, and MODE4_XGRP).
Implementations are discouraged from doing this."
"The same user confusion seen when fetching the mode also results if
setting the mode does not effectively control permissions for the owner,
group, and other users; this motivates some of the requirements that
follow."

POSIX ACL with at least one named user or named group requires that
mode group bits refers to POSIX ACL mask, and not to the POSIX ACL
group_obj (which represents owner_group).

Those RFC 8881 parts of NFS mode attribute are basically not compatible
with POSIX ACL. Your extension does not mention this problem and does
not handle it.

Existing NFS4 servers which follows the RFC 8881 meaning of mode group
bits, would not be able to implement this your extension for POSIX ACL,
because existing servers cannot change behavior of mode attribute due
backward compatibility. I think that this is a big problem.
Servers in multiprotocol environment mostly follows the RFC 8881 advice
to never return something like "POSIX mask" in group bits.

How to solve this problem. One option could be including all mode bits
into your new "posix_access_acl" attribute and let NFS4 clients to use
only "posix_access_acl" on chown operation, and never use existing
"mode" attribute at all (if the extension is supported by server).

Another option could be to introduce a new "posix_mode" attribute which
would be strictly POSIX and old "mode" attribute can stay as before for
backward compatibility. Again clients would not use "mode" attribute
anymore.


Regards,
Pali