Hide Forgot
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:
Adding Andreas as he might know more...
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.
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...
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.
I understand now - no easy way of doing what I want. Thanks for explanation Andreas - feel free to close this if you want....