why label /dev/hugepages directory hugetlbfs_t?

[Eric Paris]

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