Red Hat Bugzilla – Full Text Bug Listing
|Summary:||"cp -a" overwrites with a zero length file on NFS mount|
|Product:||[Fedora] Fedora||Reporter:||Paul Dickson <paul>|
|Component:||coreutils||Assignee:||Ondrej Vasik <ovasik>|
|Status:||CLOSED ERRATA||QA Contact:|
|Version:||6||CC:||davej, dwalsh, jacques.beigbeder, jhutar, meyering, sds, sopwith, wtogami, ykun|
|Fixed In Version:||coreutils-5.97-12.6.fc6||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2007-11-12 06:16:33 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
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 126.96.36.199, but not after 188.8.131.52 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 <firstname.lastname@example.org>. 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-184.108.40.206-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.