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

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

On Wednesday 07 August 2024 08:07:16 David Noveck wrote:
> On Tue, Aug 6, 2024, 6:21 PM Rick Macklem <[e-mail]> wrote:
> > On Tue, Aug 6, 2024 at 10:05 AM Pali Rohár <[e-mail]>
> > wrote:
> >> 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.
> >>
> >
> A similar possibility is discussed in an appendix to acls-04.   The idea is
> a read-only mode_info attribute
> that clients could use if they want to display a mode that can be displayed
> to reflect a summary of the ACL permissions.

I think that it should be the client who compose summary of the ACL
permissions. Why? Because POSIX ACL clients compute this summary
differently than NFS4 servers who follows RFC 8881 recommendation (to
not add bits from named users and named group to mode group bits).

So if you have a POSIX ACL compatible system, then its NFS4 should
report different mode to applications, than the NFS4 compatible system
which does not support POSIX ACL.

For example if you have POSIX compatible system which connects to two
different NFS4 servers, where first is POSIX ACL, second is NFS4 ACL and
you set same access control on both of them for some files (just with
simple ALLOW cases, which is supported by both POSIX and NFS4 ACL
models) then every server will report different mode. Even it both
servers will provide same access. And this is strange.