Subject: bug#20884: copying NFS4 ACLs portably

From: Michael Stone <[email-masked]>
Date: Tue, 23 Jun 2015 13:48:01 -0400

On Tue, Jun 23, 2015 at 05:39:14PM +0100, Pádraig Brady wrote:
>There have been recent changes in this area,
>so we need to know the version to help determine
>if this is a regression or was always an issue.

8.23, 8.13

On Tue, Jun 23, 2015 at 07:05:43PM +0200, Andreas Grünbacher wrote:
>I assume we are talking about a Linux client with NFSv4 in all cases.
>If so, then
>the Solaris code isn't going to be used.

Yes

>What does strace show?

relevant chunk of cp -a:

stat("tacl3", {st_mode=S_IFREG|0674, st_size=0, ...}) = 0
lstat("tacl", {st_mode=S_IFREG|0674, st_size=0, ...}) = 0
stat("tacl3", {st_mode=S_IFREG|0674, st_size=0, ...}) = 0
open("tacl", O_RDONLY|O_NOFOLLOW)       = 3
fstat(3, {st_mode=S_IFREG|0674, st_size=0, ...}) = 0
open("tacl3", O_WRONLY|O_TRUNC)         = 4
fstat(4, {st_mode=S_IFREG|0674, st_size=0, ...}) = 0
fadvise64(3, 0, 0, POSIX_FADV_SEQUENTIAL) = 0
mmap(NULL, 1056768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fecce606000
read(3, "", 1048576)                    = 0
utimensat(4, NULL, {{1434994892, 275947301}, {1434994892, 275947301}}, 0) = 0
flistxattr(3, NULL, 0)                  = 16
flistxattr(3, "system.nfs4_acl\0", 16)  = 16
open("/etc/xattr.conf", O_RDONLY)       = -1 ENOENT (No such file or directory)
fgetxattr(3, "system.nfs4_acl", 0x0, 0) = 144
fgetxattr(3, "system.nfs4_acl", "\0\0\0\6\0\0\0\1\0\0\0\0\0\0\0 \0\0\0\6OWNER@\0\0\0\0\0\0\0\0\0\0\0\26\1\207\0\0\0\6OWNER@\0\0\0\0\0\1\0\0\0\0\0\0\0\6\0\0\0\0041004\0\0\0\0\0\0\0\0\0\22\0\241\0\0\0\0041004\0\0\0\0\0\0\0\0\0\22\0\207\0\0\0\6GROUP@\0\0\0\0\0\0\0\0\0\0\0\22\0\201\0\0\0\tEVERYONE@\0\0", 144) = 144
fsetxattr(4, "system.nfs4_acl", "\0\0\0\6\0\0\0\1\0\0\0\0\0\0\0 \0\0\0\6OWNER@\0\0\0\0\0\0\0\0\0\0\0\26\1\207\0\0\0\6OWNER@\0\0\0\0\0\1\0\0\0\0\0\0\0\6\0\0\0\0041004\0\0\0\0\0\0\0\0\0\22\0\241\0\0\0\0041004\0\0\0\0\0\0\0\0\0\22\0\207\0\0\0\6GROUP@\0\0\0\0\0\0\0\0\0\0\0\22\0\201\0\0\0\tEVERYONE@\0\0", 144, 0) = 0
fgetxattr(3, "system.posix_acl_access", 0x7ffe9352d7d0, 132) = -1 EOPNOTSUPP (Operation not supported)
fsetxattr(4, "system.posix_acl_access", "\2\0\0\0\1\0\6\0\377\377\377\377\4\0\7\0\377\377\377\377 \0\4\0\377\377\377\377", 28, 0) = -1 EOPNOTSUPP (Operation not supported)
fchmod(4, 0100674)                      = 0

cp --preserve=xattr has the same system.nfs4_acl lines but lacks the 
system.posix_acl_access lines and the fchmod.

>A chmod / fchmod shouldn't clear the acl, it should only disable the permissions
>not allowed by the mode. IIRC Solaris has some weird configuration knobs for
>those kinds of things though.

That was my reading of acl(5) on solaris, but it doesn't seem to be 
what's actually happening. (At least on openindiana.)

>That would be a misbehavior / misconfiguration; --preserve=xattr should affect
>non-permission xattrs only. Which attributes are permissions and which
>are not is
>configured in /etc/xattr.conf.

Well, I can confirm that if system.nfs4_acl is configured as 
"permissions" in /etc/xattr.conf that cp ignores it entirely. So if the 
almost-desired behavior was a side effect, then I guess this whole thing 
is stuck in the old controversy about whether the acl library should 
support nfs4 acls?

Mike Stone