Bug 220908
Summary: | selinux errors copying between various labelled & unlabelled filesystems | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Need Real Name <bugzilla> |
Component: | selinux-policy-targeted | Assignee: | Daniel Walsh <dwalsh> |
Status: | CLOSED DUPLICATE | QA Contact: | Ben Levenson <benl> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 6 | CC: | eparis |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2007-04-11 17:57:51 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: |
Description
Need Real Name
2006-12-28 18:36:18 UTC
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 vfat filesystem. 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 context 'unlabeled'. 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 does). Maybe the owner of the Fedora Extra ntfs-3g module should be copied on this bug report Yes the problem is a mapping problem in policy. Should be fixed in selinux-policy-2.4.6-21 Just updated to selinux-policy-2.4.6.23. 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') Thanks, Jeff 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: ntfs-3g-0-0.9.20070118.fc6 fuse-2.6.3-1.fc6 What am I doing wrong since I believe you said that you had fixed it as of selinux-policy-2.4.6-21 ? Still not fixed -- i.e., ntfs-3g filesystems (using fuse) still show up as unlabeled. 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: kernel-2.6.20-1.2933.fc6 selinux-policy-targeted-2.4.6-42.fc6.noarch.rpm fuse-2.6.3-2.fc6.i386.rpm ntfs-3g-1.0-1.fc6 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 *** |