Displaying streams as xattrs

[Steve French]

On Fri, May 26, 2023 at 7:54 PM Steve French <smfrench at gmail.com> wrote:
>
>
>
> On Fri, May 26, 2023, 06:03 Björn JACKE <bj at sernet.de> wrote:
>>
>> On 2023-05-25 at 18:50 -0500 Steve French via samba-technical sent off:
>> > Today the "RichACLs" can be displayed multiple ways (e.g. "getcifsacl"
>> > and various other
>> > tools and also via system xattrs).
>> > Being able to display "RichACLs" makes sense - and I am fine with
>> > mapping these (and
>> > probably would make sense to at least have a readonly mapping of the
>> > existing richacls on
>> > a file to "posixacl") and RichACLs are very important.
>> >
>> > Wouldn't it be easier to let them also be queried for cifs.ko via
>> > "system.getrichacl" (or whatever
>> > the "getrichacl" tool used in various xfstests uses)?
>> >
>> > I was also wondering how we should display (and how to retrieve via
>> > SMB3) "claims based ACLs" (presumably these are reasonably common on a
>> > few server types like Windows)?
>>
>> let's stop calling them RichACLs becuase that was only the name that Andreas
>> Grünbacher was giving his implementation of the NFS4 ACLs

The name "richacls" looks like it is embedded in the standard
filesystem functional tests
(to pass xfstests generic/362 through generic/370 requires this - so I
would have to finish
off the mapping of this richacl pseudo-xattr query to the SMB3.1.1 get
acl query over the wire).
It doesn't look too bad, and it would.   Most users would probably use
the normal
tools (like getcifsacl or even Samba's "smbcacls" user space tool or
the pseudo-xattr
e.g. system.cifs_ntsd_full) but if it helps to use a common format
that helps ntfs and nfsv4.1 and later
that is fine with me.


> Remember that at Connectathon conferences years ago when nfs4.1 ACLS were explained  (fixing NFS 4 ACLS to address some missed things). The NFS ACL ideas were modelled after smb ACLs so NFS ACLs have many similarities to their predecessor SMB ACLs (although presumably do not support claims based ACEs/CBAC/DAC yet)



-- 
Thanks,

Steve