Bug 830997 - Can’t specify selinux context for ntfs partition
Can’t specify selinux context for ntfs partition
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
17
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-11 17:48 EDT by chritallic
Modified: 2013-06-10 15:51 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-01 10:47:51 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description chritallic 2012-06-11 17:48:06 EDT
Description of problem:
It is not possible to use the context option on NTFS mounts. ntfs-3g-mount reports “Invalid argument”. 


Version-Release number of selected component (if applicable):
ntfs-3g 2012.1.15 integrated FUSE 27
mount from util-linux 2.21.2 (libmount 2.21.0: selinux, debug)


Steps to Reproduce:
1. Have a ntfs formatted partition
2. Try to mount with -o context=…
  
Actual results:
$ mount -o context="system_u:object_r:user_home_t:s0" /dev/sda5 /data
ntfs-3g-mount: mount failed: Invalid argument 
$ mount -o context="system_u:object_r:user_home_t:s0",default /dev/sda5 /data
ntfs-3g-mount: mount failed: Invalid argument


Expected results:
Successfull mount and a »system_u:object_r:user_home_t:s0« context in »ls -Zd« for /data


Additional info:
In bug 502946 a similar issue has been reported but there was no error message. Moreover, in http://lists.fedoraproject.org/pipermail/users/2012-January/412830.html a user reported that this worked in Fedora 16.
Comment 1 Stephen Smalley 2012-06-12 08:20:38 EDT
Worked for me, same versions.
What dmesg do you get?
Comment 2 Stephen Smalley 2012-06-12 08:28:54 EDT
What is your kernel version?

The following worked for me:
dd if=/dev/zero of=ntfs.img bs=1M count=512
losetup --show -f ntfs.img
mkntfs /dev/loop0
mount -o context="system_u:object_r:user_home_t:s0" /dev/loop0 /mnt
ls -Zd /mnt

I tried kernel-3.3.7-1.fc17.x86_64 and 3.4.0-1.fc17.x86_64 successfully.
Comment 3 chritallic 2012-06-12 08:36:55 EDT
dmesg shows »SELinux: mount invalid.  Same superblock, different security settings for (dev sda5, type fuseblk)«.

My kernel version is 3.4.0-1.fc17.x86_64.
Comment 4 chritallic 2012-06-12 08:49:20 EDT
(In reply to comment #2)
> The following worked for me:
> dd if=/dev/zero of=ntfs.img bs=1M count=512
> losetup --show -f ntfs.img
> mkntfs /dev/loop0
> mount -o context="system_u:object_r:user_home_t:s0" /dev/loop0 /mnt
> ls -Zd /mnt
Okay, this worked for me too.

However, »mount -o context="system_u:object_r:user_home_t:s0" /dev/sda5 /mnt« still gives me
»ntfs-3g-mount: mount failed: Invalid argument«.

»fdisk -l« shows:
   Device Boot      Start         End      Blocks   Id  System
/dev/sda5        98012628   199720079    50853726    7  HPFS/NTFS/exFAT
Comment 5 Stephen Smalley 2012-06-12 08:55:57 EDT
(In reply to comment #3)
> dmesg shows »SELinux: mount invalid.  Same superblock, different security
> settings for (dev sda5, type fuseblk)«.
> 
> My kernel version is 3.4.0-1.fc17.x86_64.

This means that you have the same superblock mounted elsewhere with different or no context= option.
Comment 6 chritallic 2012-06-12 09:10:51 EDT
(In reply to comment #5)

Okay, got it working now. I always had the partition mounted at bootime and used umount before trying to use the »mount -o context=…« command. Without the partition being mounted before it works.

But why is this happening? I would expect the »mount« command to work the same way, after a proper umount. If SELinux stores the fs context for the rest of the session, even after an umount, this is definitively not what I would expect.
Comment 7 Stephen Smalley 2012-06-12 10:05:24 EDT
That does seem wrong.  SELinux stores it in the per-superblock security structure, so it should go away when the superblock is killed.  Maybe the superblock stays around with fuse because the daemon keeps a reference?
Comment 8 Justin M. Forbes 2012-09-11 11:43:28 EDT
Is this still happening with 3.5.3 kernels in updates?
Comment 9 Ian Malone 2012-10-20 18:11:02 EDT
Fedora 16 here with the same problem.

Under kernel-3.4.11-1:
mount /dev/sda1 /media/shared11 -t ntfs -o context="system_u:object_r:virt_image_t"
ntfs-3g-mount: mount failed: Invalid argument

I've tried kernel 3.6.2 from updates-testing with the same result.
Comment 10 Justin M. Forbes 2013-02-01 10:47:51 EST
This bug is being closed because it has been set needinfo for more than 2 weeks without a response. If this is still an issue, please reopen and reply with the requested information.

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