why label /dev/hugepages directory hugetlbfs_t?

Daniel J Walsh dwalsh at redhat.com
Tue Oct 12 15:01:11 UTC 2010


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/09/2010 11:30 AM, Dominick Grift wrote:
> On Sat, Oct 09, 2010 at 09:14:25AM -0400, Eric Paris wrote:
>> On Sat, 2010-10-09 at 11:43 +0200, Dominick Grift wrote:
>>> Why is /dev/hugepages specified to be labeled hugetlbfs_t? Any
>>> particular reason for this? 
>>>
>>> In my branch i labelled it device_t like most directories in /dev.
>>>
>>> This makes it easier because udev does some magic
>>> in /lib/udev/devices(hugetables) which causes all kinds of extra
>>> denials if i label the hugepages dir hugetlbfs_t.
>>>
>>> For example hugetlbfs_t must associate to device_t etc. Much easier to
>>> just label hugepages directories at both /dev/hugepage
>>> and /lib/udev/devices/hugepages device_t.
>>>
>>> Also i noticed that /sys/fs/cgroup is specified to be labeled
>>> cgroup_t, but i think the kernel creates that directory with type
>>> sysfs_t. So that would mean that it needs to be restored at each
>>> boot-up.
>>
>> /dev/hugepages and (I think) /sys/fs/cgroup are filesystem mount points
>> not actually files in the devfs or sysfs filesystem.  So the labels are
>> picked probably picked up from the filesystem labeling rules at mount
>> time rather than from a later restorecon.
> 
> In my branch i have the directory /dev/hugepages set to device_t and this location is labelled properly (udev or dracut did it?)
> Unlike /sys/fs/cgroup directory which is set to cgroup_t but this location is not labelled properly (sysfs_t instead of specified cgroup_t)
> 
>>
>> As to whether we need or want such labels on hugetlbfs and cgroupfs I'll
>> let you and Dan argue about   :)
>>
>> -Eric
>>
>>
>>
>> --
>> selinux mailing list
>> selinux at lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/selinux
I think the problem is running tools like restorecon on /dev to check
labels. ends up generating errors when hugetlbfs and cgroupfs are
mounted.  I guess we could change the label to <<none>>

/dev/shm has the same problem.

matchpathcon  /dev/shm
/dev/shm	system_u:object_r:tmpfs_t:s0

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAky0eDcACgkQrlYvE4MpobNbLwCfTuarpot9DAt9EKJZyZgEeSwK
qCEAoJfM4WUgM8V7yVY50sAjcJKSTBLx
=pDD5
-----END PGP SIGNATURE-----


More information about the selinux mailing list