[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: cp --preserve=mode and NFS4 ACLs
From: |
Ross Burton |
Subject: |
Re: cp --preserve=mode and NFS4 ACLs |
Date: |
Tue, 24 Sep 2024 18:31:46 +0100 |
Hi,
On Tue, 24 Sept 2024 at 15:28, Pádraig Brady <P@draigbrady.com> wrote:
> It would be good to see what's happening on the "working" system. I.e.
> does Fedora 40 (+ coreutils 9.4) do the fsetxattr(4, "system.nfs4_acl", ...)
> successfully?
> Note Fedora coreutils links with libacl, which may do some of the
> lifting here. Does Ubuntu also use libacl?
Debian/ubuntu do indeed link coreutils to libacl.
I have straces from various machines. On F40 it just reads the xattrs
and xattr.conf and then doesn't write anything:
flistxattr(3, NULL, 0) = 16
flistxattr(3, "system.nfs4_acl\0", 16) = 16
openat(AT_FDCWD, "/etc/xattr.conf", O_RDONLY) = 5
fstat(5, {st_mode=S_IFREG|0644, st_size=817, ...}) = 0
read(5, "# /etc/xattr.conf\n#\n# Format:\n# "..., 4096) = 817
read(5, "", 4096) = 0
close(5) = 0
close(4) = 0
close(3) = 0
> I don't think there were coreutils specific changes in this area,
> but there were related gnulib changes:
> https://github.com/coreutils/gnulib/commit/eb6a8a4dfb (included in coreutils
> 9.4)
> https://github.com/coreutils/gnulib/commit/47947855dd (not yet released)
I just got root access to this ubuntu2404 machine and experimented by
commenting out the sys.nfs4_acl line in xattr.conf, and that indeed
"solves" the problem. I suspect the cause is
https://github.com/coreutils/gnulib/commit/eb6a8a4dfb. I'm going to
explain my thinking to be sure that I'm correct. :)
cp uses gnulib which since that commit will use attr_copy_file() to
copy the xattrs. The "should I copy this attr" callback is
is_attr_permissions() which simply checks to see if the specified
xattr is annotated as a permission in xattr.conf. The problem is the
system.nfs4_acl xattr as generated by the nfs4 file system.
On fedora 40 it is not listed in xattr.conf, so the check is false,
and the xattr isn't copied.
On ubuntu 2404 (and upstream attr) it is listed in xattr.conf as a
permission attribute, so the check return is true and cp via libattr
tries to set the system.nfs4_acl attribute on the newly created file
on my ext4 file system. Which isn't allowed:
$ touch foo && xattr -w system.nfs4_acl foobar foo
[Errno 95] Operation not supported: b'foo'
So, is it a bug that cp --preserve=mode is broken when copying from
nfs to something else when ACLs are present on the server, or
intentional behaviour and the solution is to not pass --preserve=mode?
Thanks,
Ross