Bug 454072 - RHEL 5.1 - cp and chmod don't respect NFSv4 ACLs
RHEL 5.1 - cp and chmod don't respect NFSv4 ACLs
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: coreutils (Show other bugs)
All Linux
medium Severity medium
: rc
: ---
Assigned To: Ondrej Vasik
: FutureFeature
Depends On:
  Show dependency treegraph
Reported: 2008-07-04 07:37 EDT by Steve
Modified: 2011-10-11 18:15 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-09-02 05:17:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
strace -ftvo nfs4_getfacl.strace nfs4_getfacl foo (6.21 KB, application/octet-stream)
2008-07-04 08:08 EDT, Steve
no flags Details
strace -ftvo cp.strace cp --preserve=all foo bar (11.75 KB, application/octet-stream)
2008-07-04 08:10 EDT, Steve
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2009:1262 normal SHIPPED_LIVE coreutils bug fix update 2009-09-01 05:22:04 EDT

  None (edit)
Description Steve 2008-07-04 07:37:51 EDT
This is an escalation from Issue tracker.

------------------------- Original report -----------------------
Description of problem:
Acls are not respected by cp and chmod commands when accessed via NFSv4

How reproducible:
Every time.

Steps to Reproduce:
Setup a RHEL 5.1 server with NFSv4 share backed with ext3 filesystem and put an
ACL on one of the files.[1]
Setup a RHEL 5.1 client and mount the NFSv4 share. See the acl is still on the
file.[2]  Cp the file and see the new copy does not retain the ACL. 
Alternatively if you chmod the original it will remove the ACL as well.

Actual results:
When accessing files via NFSv4 the ACLs get removed.

Expected results:
ACL should remain if you make a cp or chmod via NFSv4.

Additional info:
Affected rpm: coreutils.

When looking at an strace to try to see where the issue lies you can see when
you do a nfs4_getacl it uses system.nfs4_acl call where as the cp uses
system.posix_acl_access call and is not aware of nfsv4.
------------------------- Original report -----------------------

Note that in the original report ...

[1] ACL being set from the server is the posix acl using setfacl.
[2] This posix acl gets mapped on to the NFS acl and is displayed when we use
nfs4_getfacl from the client. However, doing a getfacl from the client does not
show the posix acl.

- steve
Comment 1 Ondrej Vasik 2008-07-04 07:46:34 EDT
Could you please attach that strace(s) from issue tracker? I don't have access
Comment 2 Steve 2008-07-04 08:08:42 EDT
Created attachment 311035 [details]
strace -ftvo nfs4_getfacl.strace nfs4_getfacl foo

strace of nfs4_getfacl from the client.
Comment 3 Steve 2008-07-04 08:10:37 EDT
Created attachment 311036 [details]
strace -ftvo cp.strace cp --preserve=all foo bar

strace of cp --preserve=all foo bar executed on the client.
Comment 6 Ondrej Vasik 2008-07-08 08:35:12 EDT
I agree that it affects cp (and that cp/mv/install doesn't preserve NFSv4 ACL's
on files) - as the NFSv4 ACL's are not supported by libacl which is used by
But I don't see anything wrong with NFSv4(or better said ACL's) about chmod
command. Coreutils command chmod(man 1 chmod) has imho nothing to do with ACL's
(maybe syscall from sys/types.h (man 2 chmod) has, but this is not comming from
coreutils). Correct me if I'm wrong. 
Comment 7 Jim Meyering 2008-07-14 09:10:14 EDT
thanks for the report.
This has been addressed upstream, since coreutils-6.12, thanks to changes by
Bruno Haible in gnulib.
In case you want to try the work-in-progress, here's a relatively recent
snapshot http://meyering.net/cu/coreutils-ss.tar.gz
Comment 13 Kamil Dudka 2008-12-16 09:15:39 EST
Patch for coreutils cp/mv xattr support (which solves this bug as well) has been sent to bug-coreutils mailing list: http://lists.gnu.org/archive/html/bug-coreutils/2008-11/msg00108.html

Now it is pending for review as it is not high priority.
Comment 25 errata-xmlrpc 2009-09-02 05:17:11 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.