Bug 280331 - cp -a with NFS and selinux permissive fails, copy is empty!
cp -a with NFS and selinux permissive fails, copy is empty!
Status: CLOSED DUPLICATE of bug 219900
Product: Fedora
Classification: Fedora
Component: coreutils (Show other bugs)
7
All Linux
medium Severity low
: ---
: ---
Assigned To: Ondrej Vasik
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-09-06 07:35 EDT by Jacques Beigbeder
Modified: 2007-11-30 17:12 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-30 12:29:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Requested strace (8.04 KB, text/plain)
2007-09-06 10:50 EDT, Jacques Beigbeder
no flags Details

  None (edit)
Description Jacques Beigbeder 2007-09-06 07:35:45 EDT
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 10:00:17 EDT
If this is happening in permissive mode, it is probably not an SELinux problem.
Comment 2 Jacques Beigbeder 2007-09-06 10:09:34 EDT
(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 10:30:55 EDT
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 10:50:16 EDT
Created attachment 188841 [details]
Requested strace
Comment 5 Tim Waugh 2007-09-06 11:07:18 EDT
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 12:29:59 EDT

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

Note You need to log in before you can comment on or make changes to this bug.