This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1269951 - [RFE] ls: Add support for NFSv4 style ACLs [RHEL-7]
[RFE] ls: Add support for NFSv4 style ACLs [RHEL-7]
Status: ASSIGNED
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: coreutils (Show other bugs)
7.2
All Linux
medium Severity medium
: rc
: ---
Assigned To: Kamil Dudka
qe-baseos-daemons
: FutureFeature
Depends On:
Blocks: 1295396 1298243 1400961 1420851 1472751 767584 1305230
  Show dependency treegraph
 
Reported: 2015-10-08 10:48 EDT by Kamil Dudka
Modified: 2017-10-03 21:17 EDT (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: 767584
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 67567 None None None Never

  None (edit)
Description Kamil Dudka 2015-10-08 10:48:33 EDT
+++ This bug was initially created as a clone of Bug #767584 +++

Description of problem:

When I add NFSv4 style ACL rights to the file or directory, those are not
visible as the "+" sign in the permissions column in the ls -l listing. Do I
take it right that coreutils package is responsible for this functionality?

Also note that 'getfacl' command does not show the ACLs, I have to run nfs4_getfacl.

Thanks

--- Additional comment from Jim Meyering on 2011-12-14 14:21:41 CET ---

(In reply to comment #0)
> When I add NFSv4 style ACL rights to the file or directory, those are not
> visible as the "+" sign in the permissions column in the ls -l listing. Do I
> take it right that coreutils package is responsible for this functionality?
> 
> Also note that 'getfacl' command does not show the ACLs, I have to run
> nfs4_getfacl.

Thanks for the report.
As Kamil implies, gnulib's file-has-acl module is expected to
detect this.  It already has support for Solaris' NFSv4, so if it
does not work for Linux NFSv4, a patch to the bug-gnulib mailing
list would be most welcome.

--- Additional comment from Kamil Dudka on 2012-06-13 15:16:01 CEST ---

I have been looking closer at the encoding of NFSv4 attributes and found no easy way to detect the special ones.  The problem is that getxattr("system.nfs4_acl") succeeds for all files on a NFSv4 mount point and returns valid data, no matter if there are any special ACLs or not.

The only way to deduce that NFSv4 ACLs take effect would be to parse the data returned by getxattr() in a way similar to what nfs4-acl-tools does and this would be too expensive to be used by default in ls -l.  Moreover, there would be a maintenance overhead with the code duplicated from nfs4-acl-tools, which does not provide any library.
Comment 9 Kamil Dudka 2017-02-16 12:28:33 EST
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
Comment 10 Kamil Dudka 2017-02-16 12:34:10 EST
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
Comment 11 Kamil Dudka 2017-02-16 12:52:03 EST
(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.
Comment 13 Ondrej 2017-07-19 10:12:42 EDT
added myself to cc
Comment 14 Kamil Dudka 2017-07-24 07:35:56 EDT
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.
Comment 15 Ondrej 2017-07-25 08:43:35 EDT
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?
Comment 16 Kamil Dudka 2017-07-25 09:26:21 EDT
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.
Comment 17 Ondrej 2017-07-25 09:28:21 EDT
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....
Comment 18 Kamil Dudka 2017-07-25 11:39:53 EDT
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.
Comment 19 Ondrej 2017-08-08 04:36:33 EDT
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?
Comment 20 Kamil Dudka 2017-08-08 05:44:37 EDT
(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.
Comment 21 Andreas Gruenbacher 2017-08-08 06:00:54 EDT
> > - 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.
Comment 22 Ondrej 2017-08-08 06:27:31 EDT
> 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?
Comment 23 Andreas Gruenbacher 2017-08-08 07:14:44 EDT
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.
Comment 24 Kamil Dudka 2017-08-08 07:29:49 EDT
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.
Comment 25 Ondrej 2017-08-08 07:59:51 EDT
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...
Comment 26 Kamil Dudka 2017-08-08 08:10:41 EDT
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.
Comment 27 Andreas Gruenbacher 2017-08-08 08:21:25 EDT
I wouldn't bother putting this in a library at this point.
Comment 28 Andreas Gruenbacher 2017-08-08 16:04:17 EDT
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 ...
Comment 29 Kamil Dudka 2017-08-09 06:46:27 EDT
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.
Comment 30 Andreas Gruenbacher 2017-08-09 07:36:24 EDT
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.
Comment 31 Ondrej 2017-09-11 05:19:41 EDT
BTW: nfsv4 ACL -> Posix acls mapping done by the NFSv4 server is seriously broken.
Just opened support case #01924487 for it.

Note You need to log in before you can comment on or make changes to this bug.