RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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:
Embargoed:

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.