GNU bug report logs - #20884
copying NFS4 ACLs portably

Previous Next

To reply to this bug, email your comments to 20884 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Michael Stone <mstone <at> debian.org>
To: bug-coreutils <at> gnu.org
Subject: copying NFS4 ACLs portably
Date: Tue, 23 Jun 2015 12:02:03 -0400

I'm looking for some information before I run too far down this rathole. 
Currently cp --preserve=all will attempt to preserve both the unix modes and 
any ACL on a file. This seems to be working entirely as expected with a 
linux NFS4 client & server. If I attempt the same using a solaris 
server, the new file does not have the ACL. The problem appears to be 
that the fchmod run after the ACL is copied clears the ACL. If cp 
--preserve=xattr is used instead, then the ACL is preserved.

From the comments in the source it looks as though the fchmod is set 
after the xattrs are copied because the unix mode could interfere with 
setting the xattrs. It's also possible that setting the mode before the 
ACL could open up more permissions than desired. OTOH, blowing the ACL 
away doesn't seem useful either. Since the issue arises on an NFS mount, 
I don't see an obvious way to tailor the behavior to the platform. 

Am I missing anything in this diagnosis? Has this already been hashed 
out (my google-fu is too weak to find relevant hits)? 

Mike Stone

Message #8 received at 20884 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Michael Stone <mstone <at> debian.org>, 20884 <at> debbugs.gnu.org, 
 Andreas Gruenbacher <andreas.gruenbacher <at> gmail.com>
Subject: Re: bug#20884: copying NFS4 ACLs portably
Date: Tue, 23 Jun 2015 17:39:14 +0100

On 23/06/15 17:02, Michael Stone wrote:
> I'm looking for some information before I run too far down this rathole. 
> Currently cp --preserve=all will attempt to preserve both the unix modes and 
> any ACL on a file. This seems to be working entirely as expected with a 
> linux NFS4 client & server. If I attempt the same using a solaris 
> server, the new file does not have the ACL. The problem appears to be 
> that the fchmod run after the ACL is copied clears the ACL. If cp 
> --preserve=xattr is used instead, then the ACL is preserved.
> 
>>From the comments in the source it looks as though the fchmod is set 
> after the xattrs are copied because the unix mode could interfere with 
> setting the xattrs. It's also possible that setting the mode before the 
> ACL could open up more permissions than desired. OTOH, blowing the ACL 
> away doesn't seem useful either. Since the issue arises on an NFS mount, 
> I don't see an obvious way to tailor the behavior to the platform. 
> 
> Am I missing anything in this diagnosis? Has this already been hashed 
> out (my google-fu is too weak to find relevant hits)? 
> 
> Mike Stone

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.

Though the recent refactoring in this area in gnulib stated:

  "The Solaris and Cygwin code still uses duplicate code paths for setting
   a file mode while making sure that no acls exist and setting an explicit
   acl; this is no worse than before, but could be cleaned up. "

thanks,
Pádraig.

Message #11 received at 20884 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Grünbacher <andreas.gruenbacher <at> gmail.com>
To: Pádraig Brady <P <at> draigbrady.com>
Cc: 20884 <at> debbugs.gnu.org, Michael Stone <mstone <at> debian.org>
Subject: Re: bug#20884: copying NFS4 ACLs portably
Date: Tue, 23 Jun 2015 19:05:43 +0200

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.

What does strace show?

2015-06-23 18:39 GMT+02:00 Pádraig Brady <P <at> draigbrady.com>:
>
> On 23/06/15 17:02, Michael Stone wrote:
> > I'm looking for some information before I run too far down this rathole.
> > Currently cp --preserve=all will attempt to preserve both the unix modes and
> > any ACL on a file. This seems to be working entirely as expected with a
> > linux NFS4 client & server. If I attempt the same using a solaris
> > server, the new file does not have the ACL. The problem appears to be
> > that the fchmod run after the ACL is copied clears the ACL.

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.

Recent coreutils should usually only chmod to set the suid, sgid, or
stick flags,
or when setting acls doesn't work.

> If cp --preserve=xattr is used instead, then the ACL is preserved.

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.

Andreas

Message #14 received at 20884 <at> debbugs.gnu.org (full text, mbox):

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: Re: 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

Message #17 received at 20884 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Grünbacher <andreas.gruenbacher <at> gmail.com>
To: Michael Stone <mstone <at> mathom.us>
Cc: 20884 <at> debbugs.gnu.org, Pádraig Brady <P <at> draigbrady.com>
Subject: Re: bug#20884: copying NFS4 ACLs portably
Date: Tue, 23 Jun 2015 20:22:44 +0200

2015-06-23 19:48 GMT+02:00 Michael Stone <mstone <at> mathom.us>:
> 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.

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

Message #20 received at 20884 <at> debbugs.gnu.org (full text, mbox):

From: Michael Stone <mstone <at> mathom.us>
To: Andreas Grünbacher <andreas.gruenbacher <at> gmail.com>
Cc: 20884 <at> debbugs.gnu.org, Pádraig Brady <P <at> draigbrady.com>
Subject: Re: bug#20884: copying NFS4 ACLs portably
Date: Tue, 23 Jun 2015 14:43:45 -0400

On Tue, Jun 23, 2015 at 08:22:44PM +0200, Andreas Grünbacher wrote:
>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.

Well, moving things around on an NFSv4 filesystem is the request I 
received, not converting the ACL from NFSv4 to POSIX. :) I'm not 
convinced that it's possible to transparently map arbitrary ACLs from 
one filesystem to another given different semantics, so I'm not sure 
that's a goal worth holding up the ability to copy NFS4 ACLs 
indefinitely. Other implementations just warn when they can't preserve 
ACLs, which seems reasonable.

The current situation seems pretty bad, in that something is happening 
that seems to be almost-working, but which shouldn't be working at all. 
It's double bad that the behavior of coreutils depends on a config file 
(/etc/xattr.conf) which almost no distributions include by default. And 
if we start to include it, then something that people are currently 
using to copy NFS4 ACLs stops working (without any changes in 
coreutils).

Mike Stone

Message #23 received at 20884 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Grünbacher <andreas.gruenbacher <at> gmail.com>
To: Michael Stone <mstone <at> mathom.us>
Cc: 20884 <at> debbugs.gnu.org, Pádraig Brady <P <at> draigbrady.com>
Subject: Re: bug#20884: copying NFS4 ACLs portably
Date: Tue, 23 Jun 2015 21:13:20 +0200

2015-06-23 20:43 GMT+02:00 Michael Stone <mstone <at> mathom.us>:
> Well, moving things around on an NFSv4 filesystem is the request I received,
> not converting the ACL from NFSv4 to POSIX. :) I'm not convinced that it's
> possible to transparently map arbitrary ACLs from one filesystem to another
> given different semantics, so I'm not sure that's a goal worth holding up
> the ability to copy NFS4 ACLs indefinitely. Other implementations just warn
> when they can't preserve ACLs, which seems reasonable.

I'm not talking about converting between NFSv4 and POSIX ACLs, I'm thinking
of optionally having local NFSv4 ACL support on Linux on select file systems,
like Solaris has on ZFS.

Support for the "system.nfs4_acl" attribute could be added to gnulib; it's not
that big a deal, especially since the acl handling cleanup. I'm not
going to write
that code though.

> The current situation seems pretty bad, in that something is happening that
> seems to be almost-working, but which shouldn't be working at all. It's double
> bad that the behavior of coreutils depends on a config file
> (/etc/xattr.conf) which almost no distributions include by default.
> And if we start to include it, then something that people are currently using to
> copy NFS4 ACLs stops working (without any changes in coreutils).

Agreed, it's a mess.

Andreas

Previous Next

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