Do you see them by getfattr?  If so, you can extend the gnulib's module file-has-acl to call getxattr() and parse the output.  However, for upstream inclusion, this is a complete non-starter.  I provided a patch fixing a more serious issue with unnecessary mounts on autofs and the patch was rejected because it introduced an additional call of stat().  What you ask for would require to do something way more expensive than the additional call of stat().

No, getfattr won't show anything.
I have also opened the same bug against glibc (see bug #761438).
I do not require anything complicated, I just believe users of the NFSv4 mounted filesystem should be made aware of ACLs in the 'ls' output as now 'ls' won't show anything and if you experience problems accessing a file or directory, you have to know ("Aha, it could be NFSv4 style ACL") which is far from being elegant and friendly.

So, Kamil, what do you think? Moving to libacl/acl? 

From the changelog of acl I have seen there was already patch in libacl for NFSv4 ACL support, but was removed after being rejected by upstream. Without having it in libacl, it would probably mean another lib dependency in coreutils just for this or poluting coreutils/gnulib code (which is almost certainly unacceptable by upstream).

(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.

(In reply to comment #4)
> From the changelog of acl I have seen there was already patch in libacl for
> NFSv4 ACL support, but was removed after being rejected by upstream. Without
> having it in libacl, it would probably mean another lib dependency in coreutils
> just for this or poluting coreutils/gnulib code (which is almost certainly
> unacceptable by upstream).

Good context.
Thanks.  Do you know if upstream libacl folks are planning to add NFSv4 support some other way?

Just a matter of interest - why was v4 style ACL support rejected in libacl?
Looks like a complete nonsense to me. BTW, I agree than mapping POSIX<->NFSv4 ACLs does not do anything good.

Also note: I am trying against NetApp NAS based v4 server (there is no way I am aware of to build Linux based v4 server supporting ACL).

Ondrej

(In reply to comment #6)
> Do you know if upstream libacl folks are planning to add NFSv4 support
> some other way?

I am not aware of anybody working (neither planning to work) on this.

Let me know if I should file a support request to SEG as well?

Here is the NFSv4 ACL patch for libacl that ovasik mentioned in case anybody was interested:

http://pkgs.fedoraproject.org/gitweb/?p=acl.git;a=blob_plain;f=acl-2.2.39-nfsv4.patch;h=c6314f515bdbc7b56cf4ed8f21ace48ea2c796fe;hb=HEAD

... but I have no evidence it has been proposed to libacl upstream, neither that it has ever worked.

(In reply to comment #3)
> No, getfattr won't show anything.

Did you try it with -m -?

[ondrejv@draco it]$ getfattr -m - /proj/it/testdir
getfattr: Removing leading '/' from absolute path names
# file: proj/it/testdir
system.nfs4_acl

But result like that I get even for files not having any NFSv4 ACLs defined (on the same filesystem).

(In reply to comment #9)
> Let me know if I should file a support request to SEG as well?

Yes, please ... let them know that there is already bugzilla for it.

(In reply to comment #12)
> But result like that I get even for files not having any NFSv4 ACLs defined (on
> the same filesystem).

Sure, getfattr with no options specified only lists names of the attributes.  If you want to get their values too, you can use e.g. the --dump option.  That's why I talked about processing the data returned by getxattr() in comment #1 (and the additional burden it would introduce).

I see, thanks for the info. --dump shows something more, indeed.
SEG request filed.
Ondrej

Additional note:
Once this is solved (i.e. I see the "+" sign in the "ls" output), I would ideally also expect that the standard "getfacl" command would also work - displaying the original NFSv4 ACLs.
This would save me a hassle fiddling which ACLs are actually being used - but no conversion (Posix <> NFSv4) please.

Am I asking for too much or where this request should go?
Thanks

(In reply to comment #16)
> Additional note:
> Once this is solved (i.e. I see the "+" sign in the "ls" output), I would
> ideally also expect that the standard "getfacl" command would also work -
> displaying the original NFSv4 ACLs.

The getfacl utility is not designed to display NFSv4 ACLs.  In order to implement such a capability, we would need to duplicate the code of nfs4-acl-tools, which would introduce a maintenance nightmare.

Understood. But getfacl could use (for example) the getfattr command above to see if there are any v4 ACLs and if yes, either shout loudly "NFSv4 ACLs detected, please use nfs4_getfacl" or call nfs4_getfacl directly.

The ideal situation we should be generally aiming for is that "getfacl" keeps no intelligence at all. It would just detect the ACL type and call appropriate library for parsing.

(In reply to comment #18)
> The ideal situation we should be generally aiming for is that "getfacl" keeps
> no intelligence at all. It would just detect the ACL type and call appropriate
> library for parsing.

You can write a shell script doing exactly this without changing anything in {acl, attr, coretuils}.

Note that nfs4-acl-tools does not provide any library, so you can either use the executables only, or duplicate its code.

True. But it is not as nice because RedHat claim to support NFSv4 ACLs, but in fact it is only half way there. Given the current picture of where we are, the Operating System does not really support them, the only support is via a strange non-systematic addon package called nfs4-acl-tools which does not really integrate with the rest of the OS.

Admin still needs to be aware of v4 ACL in advance.

I do not want to start any flame here, I just wanted to point out that there is certainly a room for improvement - nfs4-acl-tools should provide a library interface and get/setfacl should be able to use it.

The only problem is if anyone really cares and if there is interest to implement such changes.

(In reply to comment #21)
> True. But it is not as nice because Red Hat claim to support NFSv4 ACLs, but in
> fact it is only half way there.

The file system driver supports NFSv4 ACLs, moreover we provide utilities to read/write them.

> I do not want to start any flame here, I just wanted to point out that there is
> certainly a room for improvement - nfs4-acl-tools should provide a library
> interface and get/setfacl should be able to use it.

This is something that needs to be discussed at the upstream level.  It is not really appropriate for a minor update of Enterprise Linux.

Additional question: Once we have the "ls -l" sorted, will commands like "cp -a" work as well (i.e. copying ACLs, too)?

Does not it work already?

cp -a implies --preserve=all, which includes --preserve=xattr

Ondrej probably means NFSv4 style ACLs - these are not handled atm.
Answer is - probably yes - as this NFSv4 support should be done in gnulib modules - so all coreutils utilities will inherit the support (of course, once the proper mechanism chosen and discussed upstream).

Just to make it clear -- NFSv4 ACLs cannot be preserved independently of other attributes, only via --preserve=xattr.  However, the request was about 'cp -a', which preserves much more than --preserve=xattr.  Hence, the problem is just already solved.  Note there was even an updated for RHEL-5 providing this functionality:

http://rhn.redhat.com/errata/RHBA-2009-1262.html

It works, indeed - sorry for the noise.

Note:
I was also talking to Samba guys about the possibility to edit NFSv4ACLs via Windows explorer (we do not have any GUI friendly NFSv4ACL editor). They said it should be no problem once there is a support in libacl. I also see no component called libacl in RHEL/Fedora bug tracker to submit a RFE/question against.

(In reply to comment #27)
> I also see no component called libacl in RHEL/Fedora bug tracker to submit a RFE/question against.

The component is called acl.  libacl is a subpackage of acl.

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.

Ok, to sum up:
The 'ls' support for NFSv4 will be difficult to achieve because of a lack of ACL library supporting NFSv4 format. As of bug #815375, the support for NFSv4 format is not likely to be built into the existing libacl library because we are waiting for richacl patches which are supposed to be the future.

However, richacl development has stalled which means we are effectively stuck here (and not only here, samba support for NFSv4 is stuck as well for the very same reason).

Am I missing something?

May I have an update on this? Have things progressed since the last status in Comment #30?

No, no progress - it is on the long term todo items. Support is not even in the Rawhide/upstream.

BTW: AT&T AST's ls(1) had NFSv4+CIFS+ZFS ACL support patches from Sun when they worked on migrating their POSIX utilities from the ancient SystemV basis to AST ... AFAIK with two manweeks if work this support can be grafted on GNU ls(1) ...

Thanks for the pointers. So basically probably get http://sourceforge.net/projects/libsunacl/ to Fedora and RHEL 6 to get the support. Or you mean something else?

Sorry for confusion, this does exactly the opposite :) ... http://oss.sgi.com/cgi-bin/gitweb.cgi?p=cattelan/FreeBSD_svn.git;a=commitdiff_plain;h=1e1095c5bb4e325ae485a4319e569c84dfb81dfa adds the NFSv4 ACL support on FreeBSD, however code differs and we don't have lpathconf function (actually, I see upstream conversation about similar stuff in chmod at http://permalink.gmane.org/gmane.comp.gnu.core-utils.bugs/19757 )

The Linux nfs client has supported the "system.nfs4_acl" attribute for a while now; this attribute exposes the on-the-wire NFSv4 ACL.  The attribute can be manipulated with the nfs4_getfacl and nfs4_setfacl utilities from the nfs4-acl-tools package, but those tools will never work on any filesystem other than nfs, and coreutils (ls, cp) are very unlikely to gain support for it.

On NFSv4 filesystems, if the server supports ACLs at all, every file has an ACL; in the trivial case, that ACL represents the file mode.

The plan for NFS4 ACL support is to get richacls merged into the mainline kernel ("system.richacl"), likely starting in the 4.6 mainline merge window and continuing into the next merge window.  Richacls are compatible with NFSv4 ACLs; code exists for supporting them locally on ext4 and xfs, in coreutils, as well as in nfsd and nfs.  (NFSv4 ACLs will be exposed to user space as richacls, as will CIFS ACLs).

Filesystems will have either richacl or POSIX ACL support, but not both at the same time.  Because NFSv4 ACLs and POSIX ACLs are quite different, NFSv4 ACLs will be supported through librichacl, not libacl.

I've been following the progress of the richacls patchset for some time now.  I do hope it goes in at some point, but some people really seem to object to it.  And even after it does go in, I'm not confident we'll see it in RHEL any time soon, though maybe my Fedora clients will be able to take some advantage of it.

This is already cloned for RHEL 7 and I doubt richacls will get to RHEL 6. Without this, support can be done only through nasty downstream patch to coreutils - and we have bad experience with such patches. WONTFIX for RHEL 6, keeping RHEL 7 opened.