Bug 143349 - Permission denied on mv on vfat mount
Permission denied on mv on vfat mount
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: coreutils (Show other bugs)
3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-19 15:16 EST by António Vieira
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version: Current
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-27 16:38:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
strace for problem (7.82 KB, text/plain)
2004-12-21 14:55 EST, António Vieira
no flags Details
strace for problem (7.82 KB, text/plain)
2004-12-21 14:55 EST, António Vieira
no flags Details
ltrace for problem (2.52 KB, text/plain)
2004-12-21 14:59 EST, António Vieira
no flags Details

  None (edit)
Description António Vieira 2004-12-19 15:16:47 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.
Comment 1 Sitsofe Wheeler 2004-12-19 17:02:02 EST
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/" ?
Comment 2 António Vieira 2004-12-20 14:56:26 EST
[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 
 
 
 
Comment 3 Sitsofe Wheeler 2004-12-20 19:22:44 EST
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.
Comment 4 Tim Waugh 2004-12-21 10:41:26 EST
Please attach the system call log:

strace mv file.txt /mnt/share/folder/ 2>log
Comment 5 António Vieira 2004-12-21 14:55:26 EST
Created attachment 108976 [details]
strace for problem
Comment 6 António Vieira 2004-12-21 14:55:51 EST
Created attachment 108977 [details]
strace for problem
Comment 7 António Vieira 2004-12-21 14:59:01 EST
Created attachment 108979 [details]
ltrace for problem
Comment 8 Tim Waugh 2004-12-23 06:47:36 EST
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.
Comment 9 António Vieira 2004-12-24 09:59:22 EST
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. 
 
Comment 10 Tim Waugh 2004-12-30 06:35:08 EST
dwalsh: please confirm this is working as designed.
Comment 11 Daniel Walsh 2005-01-03 09:09:04 EST
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
Comment 12 Aleksandar Milivojevic 2005-05-30 14:53:23 EDT
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.

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