Bug 1412184 - ls command does not detect nfsv4 acls
Summary: ls command does not detect nfsv4 acls
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: glibc
Version: 7.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Carlos O'Donell
QA Contact: qe-baseos-tools-bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-11 13:24 UTC by Ondrej
Modified: 2017-01-11 22:32 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-01-11 22:32:26 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Ondrej 2017-01-11 13:24:47 UTC
Description of problem:
ls command does detect existence of nfsv4 acls. It only detect existence of the POSIX draft acls which are no use on v4.

I believe this functionality needs to be implemented in glibc first.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. ls -l <file with acls> does not display '+' at the end of permissions column
2. 
3.

Actual results:


Expected results:


Additional info:

Comment 1 Ondrej 2017-01-11 13:49:35 UTC
Adding Andreas as he might know more...

Comment 2 Andreas Gruenbacher 2017-01-11 13:57:59 UTC
That's correct, NFSva ACLs are exposed as "system.nfs4_acl" xattrs by the NFSv4 client.  One way to support NFSv4 style ACLs properly is via richacls, which also have defined semantics on local filesystems.  The richacl kernel patches haven't been merged yet, though.

Comment 3 Ondrej 2017-01-11 14:04:40 UTC
Ok, so is there any way how to push this functionality at least to  glibc/coreutils now or we have to wait for the kernel patches for 'proper' support?
I have number of RH subscriptions so can open official support case if it helps anything...

Comment 4 Andreas Gruenbacher 2017-01-11 14:26:10 UTC
The "system.nfs4_acl" attributes aren't really helpful.  As per the protocol definition, on a server that supports NFSv4 ACLs, all files have "system.nfs4_acl" attributes even if they only have basic permissions.  User space would have to figure out which files have "trivial" ACLs by parsing the "system.nfs4_acl" value.  User and group identifiers in "system.nfs4_acl" are strings as on the NFSv4 protocol; they are not mapped to UIDs/GIDs.  The tools for messing with "system.nfs4_acl" attributes are more like debugging aids than anything else.  So the best approach as far as I can see is to ignore "system.nfs4_acl" attributes, and work on a better thought out alternative.  Richacls seem like a suitable solution.  I'm working on getting them accepted upstream which is a prerequisite for getting them into RHEL, but it's difficult and long winded.  Feel free to officially request them to be supported.

Comment 5 Ondrej 2017-01-11 15:52:18 UTC
I understand now - no easy way of doing what I want.
Thanks for explanation Andreas - feel free to close this if you want....


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