On Tue, Oct 12, 2010 at 11:54:42AM -0400, Daniel J Walsh wrote: > -----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 i have: # ls -alZ /dev | grep huge drwxr-xr-x. root root system_u:object_r:device_t:s0 hugepages # semanage fcontext -l | grep hugepages /dev/hugepages directory system_u:object_r:device_t:s0 /dev/hugepages/.* all files <<None>> /lib/udev/devices/hugepages directory system_u:object_r:device_t:s0 /lib/udev/devices/hugepages/.* all files <<None>> It appears that this way i dont have to associate hugetblfs_t to device_t However i am not sure because directory /dev/hugepages is empty here. But for me so far this works best because i run kernel confined and udev does all kinds of crazy stuff early in the boot process and this seems to work clean for me so far > > > -----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-----
Attachment:
pgpNGwkmglIWU.pgp
Description: PGP signature
-- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
