Bug 280331 - cp -a with NFS and selinux permissive fails, copy is empty!
Summary: cp -a with NFS and selinux permissive fails, copy is empty!
Status: CLOSED DUPLICATE of bug 219900
Alias: None
Product: Fedora
Classification: Fedora
Component: coreutils   
(Show other bugs)
Version: 7
Hardware: All Linux
medium
low
Target Milestone: ---
Assignee: Ondrej Vasik
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-09-06 11:35 UTC by Jacques Beigbeder
Modified: 2007-11-30 22:12 UTC (History)
1 user (show)

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: ---


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

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 ***


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