Description of problem: With selinux as permissive, cp --preserve=all on NFS fails. Copy is empty (0 bytes) Version: Fedora 7 64 bits up-to-date on Sep 6th (problem also occuring with FC6). Steps to Reproduce: cd /partition (NFS mounted, for instance localhost:/partition; so NFS server and NFS client are FC7-64) rm -f toto* date > toto1 cp -i -a toto1 toto2 cp -i -a toto1 toto2 ls -l toto* Actual results: -rw-r--r-- 1 beig hard 30 Sep 6 13:17 toto1 -rw-r--r-- 1 beig hard 0 Sep 6 13:17 toto2 <<< BUG! Expected results: -rw-r--r-- 1 beig hard 30 Sep 6 13:17 toto1 -rw-r--r-- 1 beig hard 30 Sep 6 13:17 toto2 <<< CORRECT Additional info: strace may give hints (getxattr failures??)
If this is happening in permissive mode, it is probably not an SELinux problem.
(In reply to comment #1) > If this is happening in permissive mode, it is probably not an SELinux problem. But it is Selinux-related! When setting Selinux as disabled, copy is OK. May be the bug is in cp(1), or some library used by cp(1)...
Could you attach the strace output? Run 'strace 2>strace.log cp -i -a toto1 toto2' to get a strace.log file.
Created attachment 188841 [details] Requested strace
Seems to be this code fragment from the SELinux patch to src/copy.c: @@ -302,6 +307,30 @@ { dest_desc = open (dst_name, O_WRONLY | O_TRUNC | O_BINARY); +#ifdef WITH_SELINUX + if (dest_desc >= 0 && selinux_enabled && + (x->preserve_security_context || x->set_security_context)) + { + security_context_t con; + if(getfscreatecon(&con) == -1) + { + return_val = false; + goto close_src_desc; + } + + if (con) + { + if(fsetfilecon(dest_desc, con) == -1) + { + return_val = false; + freecon(con); + goto close_src_desc; + } + freecon(con); + } + } +#endif + With SELinux not disabled we can successfully getfscreatecon(), but on this NFS file system fsetfilecon() fails. If SELinux is disabled, we skip that entire section anyway. Obviously there needs to be at least a diagnostic given if we're going to fail in this case. Probably we should only even fail if x->require_preserve is true (which is the case for 'cp -a' anyway). In another place we check for errno!=ENOTSUP as well. Not sure what the correct behaviour is here.
*** This bug has been marked as a duplicate of 219900 ***