Description of problem:
In addition to the standard ext3 filesystem, I also have partitions with
dos/vfat and ntfs-3g types.
Copying/moving files between various pairwise combinations of these labeled and
unlabeled filesystems gives selinux errors.
It seems to me that these operations should be allowed under the targeted
policy, particularly, when the user has ownership rights to the respective
directories and files.
So far, I have needed to create the following rules to allow such copies/moves,
though I am sure that there are other combinations and permutations of source
and target type contexts:
class filesystem associate;
allow dosfs_t unlabeled_t:filesystem associate;
allow file_t unlabeled_t:filesystem associate;
allow unlabeled_t dosfs_t:filesystem associate;
allow unlabeled_t fs_t:filesystem associate;
allow usr_t unlabeled_t:filesystem associate;
allow var_t unlabeled_t:filesystem associate;
I could presumably continue to add new permutations to my 'local' policy as they
come up but I suspect that there must be a better way to do this.
In any case, please let me know whether you at least agree with the premise that
under the targeted policy, the average user should be able to move/copy files
between filesystems that they have permission to.
Alternatively, maybe in my /etc/fstab, I should 'force' a context to the
unlabeled file systems????
Please advise and/or correct...
Is the unlabeled file system a ext3 file system. You can easily add a label
useing restorecon -R -v /MOUNTPOINT. Or you could us a mount option to mount it
with one context.
Something like the following
mount -o context=system_u:object_r:default_t /dev/XYZ /MOUNTPOINT
No - the unlabeled file system is an ntfs-3g filesystem and the dosfs_t is a
Again, I get selinux errors when I copy any of the following permutations:
vfat -> ntfs-3g
ntfs-3g -> ext3
ntfs-3g -> vfat
ext3 -> ntfs-3g
Presumably, similar errors would occur between ntfs-3g and any other filesystem,
since mount.ntfs-3g apparently by default mounts the ntfs-3g filesystem with
Maybe the solution is to have the ntfs-3g module assign a context to the
filesystem and mount it accordingly.
The more I think about it, the problem is really just that ntfs-3g is not
mounting the file system as type dosfs_t (which is what the older 'ntfs' mount
Maybe the owner of the Fedora Extra ntfs-3g module should be copied on this bug
Yes the problem is a mapping problem in policy.
Should be fixed in selinux-policy-2.4.6-21
Just updated to selinux-policy-184.108.40.206.
Still seeing the following in my /var/log/messages:
Jan 14 12:49:03 consult kernel: SELinux: initialized (dev fuse, type fuse), not
configured for labeling
(remember that ntfs-3g is a user-space filesystem so it uses 'fuse')
This still doesn't seem to be fixed. I have the latest selinux-policy-2.4.6-37.fc6.
I still get the boot message:
SELinux: initialized (dev fuse, type fuse), not configured for labeling
when I boot and mount the filesystem using ntfs-3g.
I am using:
What am I doing wrong since I believe you said that you had fixed it as of
Still not fixed -- i.e., ntfs-3g filesystems (using fuse) still show up as
Interestingly, though, the kernel boot error message has changed a little to:
SELinux: initialized (dev hda1, type fuseblk), not configured for labeling
I'm surprised that other people aren't having this problem since I would have
thought that by now many people would want to use ntfs-3g to read/write to
Windoze ntfs filesystems (though perhaps those people just shut off selinux :)
In any case, I would think this would be a priority bug to fix...
By the way, I am currently running:
Fixed in selinux-policy-2.4.6-49.fc6
Not sure it's fully fixed yet :)
Good news is that my ntfs-3g partitions are now labeled.
The bad news is that they are labeled as: system_u:object_r:fusefs_t
Unfortunately, the targeted policy selinux definitions don't allow for copying
between to the fusefs_t domain.
I would think that the 'average' user of an ntfs-3g filesystem would want to be
able to at least do basic file operations.
Any suggestions on the *best* way to remedy this?
That is strange, it should be labeled ntfs-3g.
Checkout bugzilla #220732
They seem happy with this fix.
I will close this bug as a duplicate and we can carry on the conversations there.
*** This bug has been marked as a duplicate of 220732 ***