Bug 830997

Summary:	Can’t specify selinux context for ntfs partition
Product:	[Fedora] Fedora	Reporter:	chritallic
Component:	kernel	Assignee:	Kernel Maintainer List <kernel-maint>
Status:	CLOSED INSUFFICIENT_DATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	17	CC:	dwalsh, eparis, gansalmon, ibmalone, itamar, jforbes, jonathan, kernel-maint, madhu.chinakonda, rob.townley, sdsmall
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-02-01 15:47:51 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description chritallic 2012-06-11 21:48:06 UTC

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 12:20:38 UTC

Worked for me, same versions.
What dmesg do you get?

Comment 2 Stephen Smalley 2012-06-12 12:28:54 UTC

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 12:36:55 UTC

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 12:49:20 UTC

(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 12:55:57 UTC

(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 13:10:51 UTC

(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 14:05:24 UTC

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 15:43:28 UTC

Is this still happening with 3.5.3 kernels in updates?

Comment 9 Ian Malone 2012-10-20 22:11:02 UTC

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 15:47:51 UTC

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.