[nfsv4] Re: Our different approaches to draft POSIX ACL support in NFSv4

[David Noveck <[e-mail]>]

On Fri, Jul 26, 2024 at 9:40 PM Rick Macklem <[e-mail]> wrote:

>
>
> On Fri, Jul 26, 2024 at 9:05 AM Chuck Lever III <[e-mail]>
> wrote:
>
>>
>>
>> > On Jul 25, 2024, at 3:36 PM, David Noveck <[e-mail]> wrote:
>> >
>> > On Thursday, July 25, 2024, Chuck Lever III <[e-mail]>
>> wrote:
>> >
>> >> I agree there should be one per file,
>> >
>> > Definitely.
>> >
>> >> and that the server's
>> >> local file system should determine which type of ACL it can
>> >> support.
>> >
>> > I would think it determines the set of types  it  an support.  This can
>> be ofen will be a singleton or the null set.
>> >
>> >> (I don't envision a scenario where one file system
>> >> could support multiple types of ACLs).
>> >>
>> > I consider it unfortunate that your vision is so limited.
>> >
>> > I expect to face the issue in the near future since Netapp supports a
>> considerable portion of the NFSv4 ACL model and will want to support the
>> draft POSIX ACL.
>> >
>> > I don't think it is reasonable to tell users that they have to get rid
>> of their existing ACLs in order to allow them to use draft POSIX ACLs.
>>
>> Hopefully this can shed a little light on the use case
>> that Linux NFSD might prefer -- I'm not denigrating any
>> other usage scenarios.
>>
>> For Linux NFSD, its local file systems can store only
>> POSIX ACLs.
>>
>> In order to provide broad compatibility with existing
>> and new clients, I'm thinking that NFSD will provide
>> GET/SETATTR capabilities that allow clients to see both
>> a mapped NFSv4 ACL and a POSIX ACL per file; the mapped
>> ACL will be created from the stored POSIX ACL to satisfy
>> GETATTR requests, and access authorization decisions will
>> be based on the stored POSIX ACL, as I believe NFSD does
>> today.
>>
> That sounds reasonable to me.  I will note that I thought
> (maybe I misinterpreted his comment) Christoph thought the
> above was a very bad idea.
>
> I am thinking that there might be use for an additional
> new attribute that tells the client which type of ACL is
> actually being stored.
> That way the client might choose to Setattr that type of
> ACL to avoid mapping, while allowing the server to provide
> both the acl and posix_acl attributes (doing mapping for the
> type not being stored in the server's file system).
>
> Another fun corner
>

Fun indeed :-)


> is handling of inheritance. POSIX draft
> ACLs allow a separate (and possibly different) ACL for
> inheritance (called the default) than the one for access.
>

In acls-04, I attempt to unify those two within the NFSv4 model, treating
default acl as made up of inheritable aces, that each have a further
visibility flag that makes them appear only in the default acl.

 FWIW, I think that approach is better than the one picked up from
windows.  I would like to be able to define default sacls, for example. I
am thinking about proposing that as v4.2 extension at some point.


> rick
>
>
>> NFSD will map incoming NFSv4 ACLs to POSIX ACLs before
>> storing them. Storing either type of ACL will wholly
>> replace the POSIX ACL that is already there.
>>
>>
>> --
>> Chuck Lever
>>
>>
>>