4:43 a.m.
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.
8:14 a.m.
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.
As to whether we need or want such labels on hugetlbfs and cgroupfs I'll
let you and Dan argue about :)
-Eric
10:30 a.m.
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
10:01 a.m.
-----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(a)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-----
10:34 a.m.
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
10:54 a.m.
-----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-----
2:45 p.m.
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-----
2:51 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 10/12/2010 03:45 PM, Dominick Grift wrote:
On Tue, Oct 12, 2010 at 11:54:42AM -0400, Daniel J Walsh wrote:
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
>
>
- --
selinux mailing list
selinux(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
Yes that will work until you mount on top of /dev/hugepages and then if
you run restorecon -R -n -v /dev it will report that /dev/hugepages is
incorrectly labeled hugetlbfs_t.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAky0vDEACgkQrlYvE4MpobNjtACeJhkIRKXrAE8zBmx2AKSK7GZP
4B8AnA3BRamRHzzxYnSV8Y9rvc2wmCS7
=moFn
-----END PGP SIGNATURE-----
4942
days inactive
4945
days old
selinux@lists.fedoraproject.org
7 comments
3 participants
participants (3)
-
Daniel J Walsh -
Dominick Grift -
Eric Paris