Hide Forgot
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 glibc is responsible for this functionality? Thanks
I'd think this is a coreutils issue rather than a glibc issue. Presumably the NFS acls are layered on top of traditional ACLs, in which case all the routines from libacl should be usable. If you run getacl on files/directories with NFSv4 ACLs, are any ACLs reported? Jeff
No, getfacl command won't show them. I have to use nfs4_getfacl to display them. Submitted RFE against coreutils package: https://bugzilla.redhat.com/show_bug.cgi?id=767584 Ondrej
Both ls(1) and getfacl(1) use libacl to check ACLs. libacl uses getxattr() to read the raw data. getxattr() belongs to glibc, but there is only a trivial wrapper around the getxattr syscall. As far as I understand the problem, there is nothing to fix or improve in glibc.
Actually, libacl uses a getxattr syscall wrapper from libattr. This issue is completely unrelated to glibc: $ gdb -q --args getfacl . (gdb) break getxattr (gdb) run Breakpoint 1, getxattr (path=0x7fffffffd1b0 ".", name=0x3316405db7 "system.posix_acl_access", value=0x7fffffffce30, size=132) at syscalls.c:223 223 { (gdb) info sym getxattr getxattr in section .text of /lib64/libattr.so.1 (gdb) list 218 return SYSCALL(__NR_fsetxattr, filedes, name, value, size, flags); 219 } 220 221 ssize_t getxattr (const char *path, const char *name, 222 void *value, size_t size) 223 { 224 return SYSCALL(__NR_getxattr, path, name, value, size); 225 } 226 227 ssize_t lgetxattr (const char *path, const char *name, I am closing this out...