GNU bug report logs - #78328
Copy fails setting system.nfs4_acl extended attribute [cp (GNU coreutils) 9.7.7-6218c]

Previous Next

To reply to this bug, email your comments to 78328 AT debbugs.gnu.org.
There is no need to reopen the bug first.

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

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

From: Ian Dall <ian <at> beware.dropbear.id.au>
To: bug-coreutils <at> gnu.org
Subject: Copy fails setting system.nfs4_acl extended attribute  [cp (GNU
 coreutils) 9.7.7-6218c]
Date: Fri, 09 May 2025 14:36:41 +0930

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.

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Ian Dall <ian <at> beware.dropbear.id.au>, 78328 <at> debbugs.gnu.org,
 Lukáš Zaoral <lzaoral <at> redhat.com>
Subject: Re: 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

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

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: Lukáš Zaoral <lzaoral <at> redhat.com>,
 Ian Dall <ian <at> beware.dropbear.id.au>, 78328 <at> debbugs.gnu.org
Subject: Re: bug#78328: Copy fails setting system.nfs4_acl extended attribute
 [cp (GNU coreutils) 9.7.7-6218c]
Date: Fri, 9 May 2025 22:23:37 -0700

[Message part 1 (text/plain, inline)]

On 2025-05-09 02:32, Pádraig Brady wrote:
> This is actually being looked at in:
> https://bugzilla.redhat.com/2363149
> 
> There is a proposed patch there.

I looked at that patch, and although it sorta works it has a memory leak 
and it issues unnecessary system calls in the normal case. I wrote a 
more comprehensive patch and installed it into Gnulib; see attached 
(which combines two Gnulib patches). I've merged this into bleeding-edge 
Coreutils on Savannah so someone who builds from Git can simply do that 
to try it out.

I hope that someone who can reproduce the bug can try this patch out. I 
didn't reproduce the bug on my RHEL 9.5 host with a NetApp NFS server, 
but NFS is kinda tricky that way.

[gnulib.patch (text/x-patch, attachment)]

Message #16 received at 78328-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Ian Dall <ian <at> beware.dropbear.id.au>
Cc: Lukáš Zaoral <lzaoral <at> redhat.com>,
 Pádraig Brady <P <at> draigBrady.com>, 78328-done <at> debbugs.gnu.org
Subject: Re: bug#78328: Copy fails setting system.nfs4_acl extended attribute
 [cp (GNU coreutils) 9.7.7-6218c]
Date: Sun, 11 May 2025 08:22:40 -0700

On 2025-05-10 23:39, Ian Dall wrote:
> This works for me.

Thanks for checking. Marking the coreutils bug report as done.

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

From: Ian Dall <ian <at> beware.dropbear.id.au>
To: Paul Eggert <eggert <at> cs.ucla.edu>, Pádraig Brady
 <P <at> draigBrady.com>
Cc: Lukáš Zaoral <lzaoral <at> redhat.com>,
 78328 <at> debbugs.gnu.org
Subject: Re: bug#78328: Copy fails setting system.nfs4_acl extended
 attribute [cp (GNU coreutils) 9.7.7-6218c]
Date: Sun, 11 May 2025 16:09:55 +0930

[Message part 1 (text/plain, inline)]

This works for me.


On Fri, 2025-05-09 at 22:23 -0700, Paul Eggert wrote:
> On 2025-05-09 02:32, Pádraig Brady wrote:
> > This is actually being looked at in:
> > https://bugzilla.redhat.com/2363149
> > 
> > There is a proposed patch there.
> 
> I looked at that patch, and although it sorta works it has a memory leak 
> and it issues unnecessary system calls in the normal case. I wrote a 
> more comprehensive patch and installed it into Gnulib; see attached 
> (which combines two Gnulib patches). I've merged this into bleeding-edge 
> Coreutils on Savannah so someone who builds from Git can simply do that 
> to try it out.
> 
> I hope that someone who can reproduce the bug can try this patch out. I 
> didn't reproduce the bug on my RHEL 9.5 host with a NetApp NFS server, 
> but NFS is kinda tricky that way.

[Message part 2 (text/html, inline)]

Previous Next

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