Bug 143349
Summary: | Permission denied on mv on vfat mount | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | António Vieira <toze> | ||||||||
Component: | coreutils | Assignee: | Daniel Walsh <dwalsh> | ||||||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | |||||||||
Severity: | medium | Docs Contact: | |||||||||
Priority: | medium | ||||||||||
Version: | 3 | CC: | dwalsh, sitsofe | ||||||||
Target Milestone: | --- | ||||||||||
Target Release: | --- | ||||||||||
Hardware: | i386 | ||||||||||
OS: | Linux | ||||||||||
Whiteboard: | |||||||||||
Fixed In Version: | Current | Doc Type: | Bug Fix | ||||||||
Doc Text: | Story Points: | --- | |||||||||
Clone Of: | Environment: | ||||||||||
Last Closed: | 2005-09-27 20:38:11 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
António Vieira
2004-12-19 20:16:47 UTC
I'm guessing here but I think your problems are selinux related (that kernel audit message seems a strong indicator). What is the output of "ls -Zdl /mnt/" ? [toze@paranoid ~]$ ls -Zdl /mnt/ drwxr-xr-x 4 system_u:object_r:mnt_t root root 4096 Dez 8 22:08 /mnt/ [toze@paranoid ~]$ ls -Zdl /mnt/share/ drwxrwxrwx 14 root root 4096 Jan 1 1970 /mnt/share/ [toze@paranoid ~]$ cat /etc/sysconfig/selinux My SELinux is: SELINUXTYPE=targeted This is a real stab in the dark but I think the mv was denied because selinux could not replicate the selinux permissions that were on the file in ext3 within the DOS filesystem. Thus selinux denied access to the file. I don't see this problem on an nfs mount and I am pretty certain you won't see this problem on media mounted with a removable context. So I'm guessing that this is a case of inconvenient defaults - the (default?) context your dos partition received doesn't allow "associate" to happen. The question becomes whether people now HAVE to mount partitions that don't support selinux with appropriate selinux permissions or can this be worked around for all filesystems that don't support selinux by default. Whether my guess is right or wrong this is bound up with selinux. Please attach the system call log: strace mv file.txt /mnt/share/folder/ 2>log Created attachment 108976 [details]
strace for problem
Created attachment 108977 [details]
strace for problem
Created attachment 108979 [details]
ltrace for problem
I expect that cp -c gives the same error. This is working as designed as far as I can tell. The SELinux policy you're running won't allow you to set that file context for the newly created file. Well, you are right. cp -c also gives the same error. If it's by design I must say I think it's no logical for a simple (without parameters) cp to work and a mv not to work. Let's face it, from a user point of view that simply does not make any sense. I hope you guys give this problem another try with an in-depth approach. Keep the good work. dwalsh: please confirm this is working as designed. No I have added a rule to allow this in selinux-policy-targeted-1.17.30-2.63 If you allow udev to mount it, it will mount it as removable_t which will allow this interaction. But if you mount it by hand you get this error. This should definitely be allowed in targeted policy. Dan Not sure if this is SELinux policy related, or mv command related. When moving file from one NFS mounted file system to another NFS mounted file system (both file systems mounted from non-Linux (and therefore non-SELinux) boxes), users are getting warnings about "security context not preserved". Since there's no security context in either sorce or destination, there's really nothing that could have been preserved in the first place. The same thing happens when moving file from NFS mounted file system to local file system (but not when moving from local file system to NFS file system, which would be more logical to me, since in that case there is a security context associated with the file that is being lost). Anyhow, in my experience this warning is really confusing to the end users. Users usually think that file is not moved, and call administrators constantly. And it's kind of annoying to see hundreds or thousands of them printed repeatedly on the screen when moving lots of files in a batch (and users are rightfully asking administrators to get rid of the warning message). Checked, on two different systems with selinux-policy-targeted 1.17.30-2.52.1 and 1.17.30-2.88. |