Bug 219900

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).

This still doesn't work under kernel-2.6.19-1.2877.fc7.

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 #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.

Created attachment 144111 [details]
Patch fixing the problem

This patch is from Trond Myklebust <trond.myklebust.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.

The kernel patch is wrong; it just hides the bug in cp.
Please reassign to coreutils.

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

*** Bug 222259 has been marked as a duplicate of this bug. ***

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

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.

What avc is this generating?

*** Bug 280331 has been marked as a duplicate of this bug. ***

*** Bug 358701 has been marked as a duplicate of this bug. ***

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.

coreutils-5.97-12.6.fc6 Testing update has been successfuly pushed for fc6 ,
closing.