Bug 280331

Summary: cp -a with NFS and selinux permissive fails, copy is empty!
Product: [Fedora] Fedora Reporter: Jacques Beigbeder <jacques.beigbeder>
Component: coreutilsAssignee: Ondrej Vasik <ovasik>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: medium    
Version: 7CC: twaugh
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-10-30 16:29:59 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:
Attachments:
Description Flags
Requested strace none

Description Jacques Beigbeder 2007-09-06 11:35:45 UTC
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??)

Comment 1 Daniel Walsh 2007-09-06 14:00:17 UTC
If this is happening in permissive mode, it is probably not an SELinux problem.

Comment 2 Jacques Beigbeder 2007-09-06 14:09:34 UTC
(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)...

Comment 3 Tim Waugh 2007-09-06 14:30:55 UTC
Could you attach the strace output?  Run 'strace 2>strace.log cp -i -a toto1
toto2' to get a strace.log file.

Comment 4 Jacques Beigbeder 2007-09-06 14:50:16 UTC
Created attachment 188841 [details]
Requested strace

Comment 5 Tim Waugh 2007-09-06 15:07:18 UTC
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.

Comment 6 Ondrej Vasik 2007-10-30 16:29:59 UTC

*** This bug has been marked as a duplicate of 219900 ***