bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#78328: Copy fails setting system.nfs4_acl extended attribute [cp (GN


From: Pádraig Brady
Subject: bug#78328: Copy fails setting system.nfs4_acl extended attribute [cp (GNU coreutils) 9.7.7-6218c]
Date: Fri, 9 May 2025 10:32:44 +0100
User-agent: Mozilla Thunderbird Beta

On 09/05/2025 06:06, Ian Dall wrote:
Here, /var/tmp is on an nfs4 filesystem and /tmp is a tmpfs filesystem.

  $ touch /var/tmp/foo
  $ cp -p /var/tmp/foo /tmp

cp: preserving permissions for ‘/tmp/foo’: Operation not supported

   --preserve=mode has the same result
   --no-preserve=xattr has no effect

With nfs4 filesystems, files the system.nfs4_acl extended attribute
is always set, representing at least the traditional user, group and
mode settings but system.nfs4_acl can not be set on other filesystems.

The copy_reg() function sets the traditional user, group and mode of
the destination before trying to copy the acl with
xcopy_acl(). Including system.nfs4_acl in /etc/xattr.conf has no effect
as xcopy_acl() does not check /etc/xattr.conf.

To be clear, the destination file does get its mode set correctly (if
there are no extra entries in the acl), but cp exits with error status
even if system.nfs4_acl has never been explicitly set. This breaks
scripts that check for cp exit status.

It is not clear exactly what the correct behaviour is since in some
circumstances it would be important to fail if access control lists
are not copied successfully. Maybe system.nfs4_acl should be parsed to
see if there are any additional entries beyond A::OWNER@, A::GROUP@
and A::EVERYONE@? Or at least provide a way to suppress trying to
copying acls, perhaps --no-preserve=acl.

This is actually being looked at in:
https://bugzilla.redhat.com/2363149

There is a proposed patch there.

cheers,
Pádraig





reply via email to

[Prev in Thread] Current Thread [Next in Thread]