Bug 454072 - RHEL 5.1 - cp and chmod don't respect NFSv4 ACLs
RHEL 5.1 - cp and chmod don't respect NFSv4 ACLs
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: coreutils (Show other bugs)
5.3
All Linux
medium Severity medium
: rc
: ---
Assigned To: Ondrej Vasik
: FutureFeature
Depends On:
Blocks:
  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:
Environment:
Last Closed: 2009-09-02 05:17:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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
there.
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
coreutils. 
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.

http://rhn.redhat.com/errata/RHBA-2009-1262.html

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