GNU bug report logs - #20884
copying NFS4 ACLs portably

Previous Next

Full log

View this message in rfc822 format

From: Michael Stone <mstone <at> mathom.us>
To: Pádraig Brady <P <at> draigBrady.com>, Andreas Grünbacher <andreas.gruenbacher <at> gmail.com>
Cc: 20884 <at> debbugs.gnu.org
Subject: bug#20884: copying NFS4 ACLs portably
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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.