Re: why label /dev/hugepages directory hugetlbfs_t?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

On 10/12/2010 11:34 AM, Eric Paris wrote:
> On Tue, 2010-10-12 at 11:01 -0400, Daniel J Walsh wrote:
>> 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   :)
> 
>> 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
> 
> But isn't /dev/shm just a normal tmpfs, not a special FS like cgroupfs
> or hugepagefs?  I'm not saying the <<none>> isn't the right answer for
> things under /dev/shm/ but it's not exactly the same problem....
> 
> -Eric
> 

Not sure I see the difference.  We are talking about directories on
special file systems like /dev and /sys that have files systems mounted
on them.

tmpfs on /dev/shm type tmpfs (rw,rootcontext="system_u:object_r:tmpfs_t:s0")

This shows that a tmpfs file system is mounted on /dev/shm.  I could
leave /dev/shm as labeled device_t, but we label it tmpfs_t so that
tools looking at /dev/ will not report a labeling problem.  To me this
looks like the same thing we are doing with /dev/hugepages


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

iEYEARECAAYFAky0hMEACgkQrlYvE4MpobNcxQCgzuRQTtZN8KnU3QkO86J2gF1y
2YkAoNDgF0yMxm7ndjHlLEG0WZT3wPJh
=AmvQ
-----END PGP SIGNATURE-----
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux


[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux