Red Hat Bugzilla – Bug 143349
Permission denied on mv on vfat mount
Last modified: 2007-11-30 17:10:57 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (compatible; Konqueror/3.3; Linux) (KHTML, like Gecko) Description of problem: I have a vfat mount with the following fstab: /dev/hdb5 /mnt/share vfat users, umask=000,iocharset=iso8859-1, codepage=850 0 0 I'm running as root in a shell console. I'm trying to move a file from my home to the vfat share folder. [root@paranoid ~]# ls /mnt/share/folder/ [root@paranoid ~]# mv file.txt /mnt/share/folder/ mv: cannot create regular file `/mnt/share/folder/file.txt': Permission denied [root@paranoid ~]# ls /mnt/share/folder/ [root@paranoid ~]# Now, if I do a simple 'cp' instead of an 'mv' I get: [root@paranoid ~]# cp file.txt /mnt/share/folder/ [root@paranoid ~]# ls /mnt/share/folder/ file.txt It's even worst, If the file is already in the destination folder (after this copy) because it removes the destination file: [root@paranoid ~]# mv file.txt /mnt/share/folder/ mv: overwrite `/mnt/share/folder/file.txt'? y mv: cannot create regular file `/mnt/share/folder/file.txt': Permission denied [root@paranoid ~]# ls /mnt/share/folder/ [root@paranoid ~]# As you can see, it's perfectly possible to delete and to copy the file in each end. [root@paranoid ~]# cp file.txt /mnt/share/folder/ [root@paranoid ~]# rm /mnt/share/folder/file.txt rm: remove regular file `/mnt/share/folder/file.txt'? y [root@paranoid ~]# rm file.txt rm: remove regular file `file.txt'? y [root@paranoid ~]# I tried to do it the other way arround, from vfat to ext3 and it has another strange behaviour related with security context: [root@paranoid ~]# echo ola > /mnt/share/folder/file.txt [root@paranoid ~]# cp /mnt/share/folder/file.txt . [root@paranoid ~]# mv /mnt/share/folder/file.txt . mv: overwrite `./file.txt'? y mv: warning: security context not preserved `/mnt/share/folder/file.txt': Operation not supported [root@paranoid ~]# Version-Release number of selected component (if applicable): coreutils-5.2.1-31 How reproducible: Always Steps to Reproduce: 1.Mount a vfat filesystem 2.Create a file in a ext3 filesystem 3.Try to move the file to the destination (mv /mnt/home/file1 /mnt/vfatdir/) Actual Results: Permission denied in move command Expected Results: The file copied, because cp caused no permission errors. Additional info: Maybe this is a SELinux issue with mv? Appears to be so - the following message was added into the /var/log/messages: Dec 19 20:00:05 paranoid kernel: audit(1103486405.154:0):avc: denied { associate } for pid=3710 exe=/bin/mv name=file.txt scontext=user_u:object_r:user_home_t tcontext=system_u:object_r:dosfs_t tclass=filesystem Also tried moves without crossing filesysteams and that appears to work. I've tried do a Konqueror move and it worked - I'm not sure how it works but I'm quite positive it doesn't use the 'mv' command.
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.