Bug 219900

Summary: "cp -a" overwrites with a zero length file on NFS mount
Product: [Fedora] Fedora Reporter: Paul Dickson <paul>
Component: coreutilsAssignee: Ondrej Vasik <ovasik>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 6CC: davej, dwalsh, jacques.beigbeder, jhutar, meyering, sds, sopwith, wtogami, ykun
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: coreutils-5.97-12.6.fc6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-11-12 06:16:33 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 207681    
Attachments:
Description Flags
Patch fixing the problem none

Description Paul Dickson 2006-12-15 21:29:58 EST
Description of problem:
I tried to backup a file with "cp -a toc toc~".  The toc~ already existed, and
the result was a zero length version of toc~.  This doesn't happen on my local
HD volumes.

Version-Release number of selected component (if applicable):
kernel-2.6.18-1.2849.fc6

How reproducible:
Always

Steps to Reproduce:
1. ls -l >toc
2. cp -a toc toc~
3. ls -l toc*
4. cp -a toc toc~
5. ls -l toc*
  
Actual results:
-rw-rw-r-- 1 dickson dickson 256 Dec 15 19:12 toc
-rw-rw-r-- 1 dickson dickson   0 Dec 15  2006 toc~

Expected results:
-rw-rw-r-- 1 dickson dickson 256 Dec 15 19:12 toc
-rw-rw-r-- 1 dickson dickson 256 Dec 15 19:12 toc~

Additional info:
If I rm the destination first, the copy works.  It also works without the -a
argument.
Comment 1 Paul Dickson 2006-12-15 21:37:13 EST
It works OK from another system running kernel-2.6.18-1.2798.fc6 talking to the
same server (kernel-2.6.18-1.2708.fc6).
Comment 2 Paul Dickson 2006-12-18 23:12:33 EST
This still doesn't work under kernel-2.6.19-1.2877.fc7.
Comment 3 Paul Dickson 2006-12-18 23:44:53 EST
I just noticed that it works under 2.6.18.1, but not after 2.6.18.2 according to
the changelog of the above kernels.
Comment 4 Paul Dickson 2006-12-19 12:37:13 EST
Comment #3 is apparently a false lead.  The problem goes away if I switch
SELinux from Permissive to Disabled.  The other machines are running with it
disabled.
Comment 6 Paul Dickson 2006-12-20 10:37:26 EST
Created attachment 144111 [details]
Patch fixing the problem

This patch is from Trond Myklebust <trond.myklebust@fys.uio.no>.  I tested a
kernel I compiled from an SRPM to confirm the problem still occurred, then I
applied this patch and retested.  This patch fixes my problem.
Comment 7 Stephen Smalley 2007-01-29 08:29:02 EST
The kernel patch is wrong; it just hides the bug in cp.
Please reassign to coreutils.
Comment 8 Jim Meyering 2007-01-30 10:46:58 EST
Thanks for the info.
I have reproduced the problem.

I'm in the process of changing how the upstream version of cp -a works.
It will try to preserve context, and give a diagnostic for any failure,
but failure to preserve context will not change its exit status.
However, with "cp --preserve=context" or "cp --preserve=all", failure
to preserve context *will* make cp exit with nonzero status.

I'd like to add a test script to exercise this fix, but depending on
the existence of a writable, NFS-mounted partition is not a recipe for
good coverage.  Can anyone suggest an easier way to provoke fsetfilecon
failure on a file we've just opened (but not created -- it already existed)
for writing?

Here are the tests (run in an empty nfs-mounted directory, on a system with
e.g., SELINUX=permissive (not "disabled")):

Test1 (/bin/cp from coreutils-6.7-3.fc7 would fail this one)
  fail=0
  echo foo > f; cp f ff; cp -a f ff || fail=1
  test -s ff || fail=1
  test $fail = 0 || echo fail

Test2
  fail=0
  # Expect the latter cp to fail:
  echo foo > f; cp f ff; cp --preserve=context f ff && fail=1
  test $fail = 0 || echo fail
Comment 9 Daniel Walsh 2007-02-14 16:09:59 EST
*** Bug 222259 has been marked as a duplicate of this bug. ***
Comment 10 Jan Hutaƙ 2007-10-29 15:36:41 EDT
Hello,
I can see this also in F8:

coreutils-6.9-6.fc8
kernel-2.6.23.1-37.fc8
nfs-utils-1.1.0-6.fc8

# mount -t nfs4 localhost:/ /mnt/tmp/
# cd /mnt/tmp/
# echo "hello" > f
# cp f ff
# /bin/cp -a f ff
# cmp f ff && echo PASS
cmp: EOF on ff

# ls -Z f ff
-rw-r--r--  root root system_u:object_r:nfs_t:s0       f
-rw-r--r--  root root system_u:object_r:nfs_t:s0       ff
# ls -l f ff
-rw-r--r-- 1 root root 6 2007-10-29 20:31 f
-rw-r--r-- 1 root root 0 2007-10-29 20:31 ff

Hope this helps,
Jan
Comment 11 Ondrej Vasik 2007-10-30 05:51:19 EDT
I have the same report in #280331 (maybe a bit different- for SELinux) and for
RHEL5(#320771). Problem seems to be fixed in latest upstream snapshot - it
worked for me there. (http://meyering.net/cu/coreutils-6.9-ss.tar.gz) - I'm
trying to find out what has fixed this cp -a , you may use cp -dRpP with success
even with the current versions, so I hope it will be easy fix and will be
finished soon.
Comment 12 Daniel Walsh 2007-10-30 06:36:19 EDT
What avc is this generating?
Comment 13 Ondrej Vasik 2007-10-30 12:30:00 EDT
*** Bug 280331 has been marked as a duplicate of this bug. ***
Comment 14 Ondrej Vasik 2007-10-30 14:06:00 EDT
*** Bug 358701 has been marked as a duplicate of this bug. ***
Comment 15 Ondrej Vasik 2007-10-30 14:08:31 EDT
F-7 , F-8 and RAWHIDE packages for that bug are hopefully fixed. FC-6 one will
need some changes, will be built hopefully tomorrow.
Comment 16 Ondrej Vasik 2007-11-12 06:16:33 EST
coreutils-5.97-12.6.fc6 Testing update has been successfuly pushed for fc6 ,
closing.