Bug 1269951

I see richacl package is now available in Fedora (bug #1218362).  However, I see no Fedora neither Vanilla kernel with richacl support.  How can we test it then?

Also, as I understand it, librichacl is not going to be able to read NFSv4 ACLs on existing kernels.  It is a user-space library to access Richacls, which are an implementation of NFSv4 ACLs but uses a different namespace (system.nfs4_acl vs. system.richacl):

https://github.com/kvaneesh/richacl-tools/blob/b4c45991/librichacl/richacl_xattr.h#L42

The project page http://www.bestbits.at/richacl/ references patches for gnulib and coreutils but I have no idea if they have ever been proposed upstream:

https://github.com/andreas-gruenbacher/gnulib
https://github.com/andreas-gruenbacher/coreutils

(In reply to Kamil Dudka from comment #9)
> https://github.com/kvaneesh/richacl-tools/blob/b4c45991/librichacl/
> richacl_xattr.h#L42

While the above link is clearly incorrect (no idea why Google preferred it over the upstream git repository), the namespace system.richacl is still being used.

added myself to cc

There is currently no plan to make this supported in GNU coreutils upstream and there is no generic enough library available that could be used to parse the data of the extended attributes.  We can reconsider this once the situation changes.

To clarify - this also means 'cp -a','tar' and other utilities silently ignores nfsv4 xattrs -> effectively meaning we have no means to safely copy/backup filesystem using these ACLs, right?

This is luckily not the case.  Both 'cp -a' and 'tar --xattr' preserve extended attributes, which are used to transfer the NFSv4 ACLs from kernel to user space and back.  This low-level representation is not portable across different systems but it should work fine for backups.

Ok, that's good. Bad thing is, that it does not print any error/warning if we copy to a filesystem which doesn't support it (i.e. ext3,ext4, btrfs,any linux local fs actually).

I think we should at least print out some warning that these attrs could not be preserved....

Good point.  This is actually the documented behavior of 'cp -a':

     Try to preserve SELinux security context and extended attributes (xattr),
     but ignore any failure to do that and print no corresponding diagnostic.

For backup purposes, it is better to use 'cp --preserve=xattr ...' to detect
possible data loss.

Ok, thanks for the clarification.
So to sum up:
- we have richacl package in RHEL but no support for richacl in the kernel (very confusing)
- we can't expect richacl kernel support in any foreseeable future
- 'ls -l' will probably never inform user about the extra NFSv4 ACLs
- nfs4_setfacl is buggy (see bugs #1416683 and #1416688)

Given the facts above, there is currently no way to build Linux based NFSv4 server which properly supports ACLs following the standard in RFC7530. The only known way is to use Solaris or Netapp.

Am I right?

(In reply to Ondrej from comment #19)
> - we have richacl package in RHEL but no support for richacl in the kernel
> (very confusing)

As far as I know, we do not have the richacl package in RHEL, only in Fedora.

> - we can't expect richacl kernel support in any foreseeable future

We would need to open a kernel bug to get an authoritative answer I guess.

> - 'ls -l' will probably never inform user about the extra NFSv4 ACLs

Unfortunately not in the nearest future.

> > - we have richacl package in RHEL but no support for richacl in the kernel
> > (very confusing)
> 
> As far as I know, we do not have the richacl package in RHEL, only in Fedora.

Indeed.

> > - we can't expect richacl kernel support in any foreseeable future
> We would need to open a kernel bug to get an authoritative answer I guess.

Upstream (in this case, Christoph Hellwig) is opposed to the kernel patches and there are no strong outside voices pushing for the acceptance of this feature, so richacls are very unlikely to make progress.

> > - 'ls -l' will probably never inform user about the extra NFSv4 ACLs
> Unfortunately not in the nearest future.

That alone wouldn't be very hard to fix.

> That alone wouldn't be very hard to fix.
Can you advise how? As Kamil says in his first comment, we would have to parse string acls every time - which is perhaps too expensive just for need of 'ls -l'.
We could perhaps only count the number of ACEs - if it's > 3, then it's likely the file has an additional ACL on it. Not sure how expensive that would be?

Parsing the "system.nfs4_acl" attribute is certainly necessary.  I'm not necessarily convinced this is too expensive though; at least it wouldn't affect non-NFSv4 filesystems much because they don't have that attribute.

An ACL is "unnecessary" if it represents the same permissions as the file mode.  Determining exactly when that is the case is hard, but coming up with a heuristic that gets it right in all practically relevant cases isn't too awful.  Here's how I've implemented that for richacls:

  https://github.com/andreas-gruenbacher/richacl/blob/master/lib/richacl_equiv_mode.c

That algorithm could be used without changing it very much.

The problem is that such code should be located at a single place in the system (a shared library preferably).  Maintaining the code separately in each program that needs to check presence of NFSv4 ACLs is just not right.

And is there any chance we would need the code more times? Probably yes.
So what if we make it part of the libacl package? Seems natural to me...

I guess this topic would be more suitable for an upstream mailing list.  Anyway, your proposal seems to be out of libacl scope.  This is how we describe the package:

    This package contains the libacl.so dynamic library which contains
    the POSIX 1003.1e draft standard 17 functions for manipulating access
    control lists.

I wouldn't bother putting this in a library at this point.

One more thing about ACLs that are equivalent to a file mode (an which ls doesn't flag with a + indicator): when copying or moving a file with such an acl to a filesystem that doesn't support the "system.nfs4_acl" attribute, the file mode should be set appropriately and no warning should be issued that the "system.nfs4_acl" attribute cannot be preserved ...

I admit this is completely out of my area of expertise but I do not understand why NFSv4 files have the "system.nfs4_acl" attribute when they in fact have no special ACLs.  This approach complicates a lot of things.  If the attribute was used only where necessary, the check for 'ls -l' would be a one-liner and the feature you propose for 'cp' would already work.  As it is now, it looks to me like there is a design flaw in the file system driver, which needs to be worked around at various places in the user space.

The NFSv4 protocol defines that when the ACL attribute of a file is requested and that file doesn't have a real ACL, an ACL that corresponds to the file mode is returned.  The "system.nfs4_acl" xattr is exactly the ACL attribute, which is why every file on NFSv4 has that xattr.  The NFSv4 client could be smart and filter out trivial "system.nfs4_acl" xattrs, but it does none of that.

From a design point of view, the flaw is already in the protocol: making up an ACL out of the mode in the server only to painfully reverse that process on the client (in the kernel or in this case, in user space) isn't useful at all.

The "system.nfs4_acl" xattr has another problem as well: it doesn't map from the on-the-wire user and group names to their local representations as UIDs and GIDs.  For recognizing mode-equivalent ACLs, that luckily doesn't matter, though.

BTW: nfsv4 ACL -> Posix acls mapping done by the NFSv4 server is seriously broken.
Just opened support case #01924487 for it.

There is no system library capable of checking the presence of NFSv4 ACLs.  It would be necessary to reimplement a significant portion of the nfs4-acl-tools' code in coreutils or gnulib, which would be unacceptable for upstream.  Therefore I am closing this bug as CANTFIX.