Re: cp --preserve=mode and NFS4 ACLs

[Ross Burton]

So the greater context of this is that I'm trying to copy a file from
a NFS server, preserving mode and timestamp. The current script does
`cp -a` which as discussed here breaks when it tries to preserve the
mode.  Looking at our use case, the only things we actually care about
is the timestamp and user executable bit.  In my testing the u+x bit
is always preserved and --preserve=mode mainly impacts whether the
umask is respected or not.  Am I missing any fine details or is
--preserve=timestamps sufficient for our needs?

Thanks,
Ross

On Tue, 24 Sept 2024 at 18:31, Ross Burton <ross@burtonini.com> wrote:
>
> 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