bug#20884: copying NFS4 ACLs portably

[Andreas Grünbacher]

2015-06-23 19:48 GMT+02:00 Michael Stone <address@hidden>:
> 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
> address@hidden@address@hidden@\0\0",
> 144) = 144
> fsetxattr(4, "system.nfs4_acl", "\0\0\0\6\0\0\0\1\0\0\0\0\0\0\0
> address@hidden@address@hidden@\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.

The -a flag is supposed to be equivalent to -dR --preserve=all, so cp
tries to copy xattrs and permissions here.
In the latter case, it only copies xattrs; that's why it's not
accessing "system.posix_acl_access" there.

Gnulib and coreutils don't have specific support for the
"system.nfs4_acl" attribute; here, they treat it like a
normal xattr. As you say, once added to /etc/xattr.conf, it's no
longer being copied.

>> 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?

Somewhat. The "system.nfs4_acl" attribute is nfs specific though: its
format isn't
well suited for other file systems. Adding support to gnulib would only make
copying permissions on nfs work, not across different file system types.

I'm currently working on richacls which should eventually work for all
types of file
systems. Patches that work as long as all users or groups have a uid/gid mapping
are available for nfs and ext4; I'll make unmapped nfs users and groups work as
well.

Andreas