Bug 103218

Summary: "cp -p" a root.root owned file/directory to a NFS mount results in a root.root owned file/directory on nfs mount, even with root_squash turned enabled
Product: [Retired] Red Hat Linux Reporter: Christopher C. Weis <ccweis>
Component: nfs-utilsAssignee: Steve Dickson <steved>
Status: CLOSED NOTABUG QA Contact: Ben Levenson <benl>
Severity: medium Docs Contact:
Priority: medium    
Version: 9Keywords: Security
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-09-10 17:57:30 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Christopher C. Weis 2003-08-27 20:04:39 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225

Description of problem:
A user attempted to copy some files from a CD-ROM drive to his NFS-mounted home
directory.  The files on the CD-ROM were (of course) user=root, group=root
-owned.  The user used the "cp -a" command to copy the files, which generated...

cp: preserving permissions for `<filename>': Operation not permitted

... as it should have for each file and directory.  However, upon doing a "ls
-l" of the files, they were user/group=root, not his own user and group.

I did a bunch more testing and found that copying (with ownership preservation)
any root:root file/directory to an NFS mount results in the file/directory being
owned by root:root, not the person who did the copying.  This does not seem to
occur when copying to a non-NFS mount.

The NFS server is running HPUX 11.11, and the RH9 client(s) are all fully
patched as of 2:30 CST USA.

Version-Release number of selected component (if applicable):
nfs-utils-1.0.1-3.9, kernel-2.4.20-20.9

How reproducible:
Always

Steps to Reproduce:
1. Copy a root:root owned file (such as /etc/passwd) to a NFS-mounted directory
as someone other than root using the "-p" option.
2. Verify that the "Operation no permitted" error it given.
3. Do an ls -l on the file to see that it is still owned by root.
    

Actual Results:  (my home directory is NFS mounted)

[ccweis@a-lnx000 ccweis]$ cd ~/testdir
[ccweis@a-lnx000 testdir]$ ls -al
total 8
drwxr-xr-x    2 ccweis   csg            96 Aug 27 14:51 .
drwx--x--x   89 ccweis   csg          8192 Aug 27 14:51 ..
[ccweis@a-lnx000 testdir]$ cp -p /etc/passwd .
cp: preserving permissions for `./passwd': Operation not permitted
[ccweis@a-lnx000 testdir]$ ls -al
total 16
drwxr-xr-x    2 ccweis   csg            96 Aug 27 14:52 .
drwx--x--x   89 ccweis   csg          8192 Aug 27 14:51 ..
-rw-r--r--    1 root     root         2325 Aug 27 12:24 passwd

(This is not good)


Expected Results:  (now with a non-NFS mounted destination)

[ccweis@a-lnx000 testdir]$ cd /tmp/testdir
[ccweis@a-lnx000 testdir]$ ls -al
total 4
drwxr-xr-x    2 ccweis   csg          1024 Aug 27 14:53 .
drwxrwxrwt   19 root     root         3072 Aug 27 14:53 ..
[ccweis@a-lnx000 testdir]$ cp -p /etc/passwd .
[ccweis@a-lnx000 testdir]$ ls -al
total 7
drwxr-xr-x    2 ccweis   csg          1024 Aug 27 14:53 .
drwxrwxrwt   19 root     root         3072 Aug 27 14:53 ..
-rw-r--r--    1 ccweis   csg          2325 Aug 27 12:24 passwd


Additional info:

-- I haven't tested things such as suid root scripts yet, which could be a MAJOR
security issue if the clients don't use the "nosuid" option when mounting the
NFS shares.  

-- I have verified that copying entire directory trees follow this same behavior.

-- I've tried rolling back to the last nfs-utils package as well as the last
kernel, but the results were always the same.

-- The behavior is reproducible on all of our RH9 NFS clients (although I
haven't tested RH7.x or RH8)