Hello Bjoern, thanks for raising this point! > If there is something the the Linux VFS layer should *really* add to help > interopearbility with basically all other major OS implementations is NFSv4 > ACLs. Seriously, for so many people living with Linux is a real pain due to > the lack of NFS4 ACLs here. [...] > The NFS4 ACL model needs to be supported by the Linux kernel also to be really > helpful. The nfs4-acl-tools are there to manage NFS4 ACLs already. To become > really helpful for Linux NFS4 ACLs need to be managable natively and also be > supported with generic filesystems and tools. > I've seen people who abandon to use Linux as client machines because of the > lack of ACL managability. Have in mind that the so called POSIX ACLs are not a FWIW: I can second that: Many of our clients (as in customers) run (for example) Linux HPC cluster headnodes with directly attached storage. For them, exporting a local filesystem like ext4 or XFS via NFS *and* SMB is an important use-case. They don't have the time and expertise to dive into VFS modules and quirks of NFSv4-to-POSIX-ACL mappings. So they actually limit themselves to just standard permission bits and write cron jobs to regularly reset permissions. Even if we manage to come up with a working setup for them, it's going to be fragile in multiple dimensions. It's a pain. Having consistent and powerful ACL support and enforcement across all access paths (remote shell, NFS, SMB) that just works would be a huge leap forward for them. Having cp -a retain the ACLs and their effects during copy from NFS mount to local /tmp and back to an SMB mount would be a dream come true. -- Thanks, Michael ________________________________________ From: samba-technical <samba-technical-bounces@xxxxxxxxxxxxxxx> on behalf of Björn JACKE via samba-technical <samba-technical@xxxxxxxxxxxxxxx> Sent: 26 May 2023 18:03:20 To: Steve French Cc: CIFS; samba-technical; Jeremy Allison; Christoph Hellwig Subject: Re: Displaying streams as xattrs Caution: External email. Do not open attachments or click links, unless this email comes from a known sender and you know the content is safe. 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, which however never mede it upstream to the kernel. Andreas is no longer interested in working on those actually because because of a long lack of interest by the Kernel maintainers back in those days. In any case, NFS4 ACLs are the right name, even if the SMB people don't like the "NFS" in the name. We have a summary of the state of NFS4 ACLs here: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.samba.org%2Findex.php%2FNFS4_ACL_overview&data=05%7C01%7Cmichael.weiser%40atos.net%7C359c5b89a4aa453c20c108db5e02cb6a%7C33440fc6b7c7412cbb730e70b0198d5a%7C0%7C0%7C638207138314989061%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=96X1GeVCoPYo1s3wmxtiDMdnXkR%2Bn%2Bw%2BcVfILLB3HGo%3D&reserved=0 . I recommend taking a closer look at this. If cifs.ko would add a mapping of SMB ACLs to the corresponding system.nfs4_acl EA, this would be nice already but It will only be a limited help if cifs.ko. The NFS4 ACL model needs to be supported by the Linux kernel also to be really helpful. The nfs4-acl-tools are there to manage NFS4 ACLs already. To become really helpful for Linux NFS4 ACLs need to be managable natively and also be supported with generic filesystems and tools. I've seen people who abandon to use Linux as client machines because of the lack of ACL managability. Have in mind that the so called POSIX ACLs are not a standardized permission model. The POSIX ACLs never passed the status of a draft standard and the only standardized ACL permission model are in fact the NFS4 ACLs. One of the main reason why FreeNAS or TrueNAS these days are based on FreeBSD is the lack of NFS4 ACLs also. I really wonder why the responsible people in the Kernel developer community ignore this important topic since so many years. Would be nice to see them join this thread ... Björn
