When using the Nvidia proprietary drivers, the files /dev/nvidiaN and /dev/nvidiactl don't get the right context. That has been discussed here and elsewhere previously. As I've understood it, it has to be fixed in the proprietary code somewhere.
To work around the problem until there is a proper fix, if ever, I added
/dev/nvidia0 /dev/nvidiactl
to /etc/selinux/restorecond.conf. But now I get a complaint about restorecond not being allowed to relabel those files:
type=AVC msg=audit(1312575006.803:33): avc: denied { relabelto } for pid=905 comm="restorecond" name="nvidiactl" dev=devtmpfs ino=18490 scontext=system_u:system_r:restorecond_t:s0 tcontext=system_u:object_r:xserver_misc_device_t:s0 tclass=chr_file
SEtroubleshoot suggests to audit2allow to make a module to allow that. I'll do that, so I can work around this problem too.
But I am a bit suprised by the need. Why isn't restorcond (or more properly, restorecond_t) allowed to relabel everything? Isn't that what it is all about?
I did a "sesearch --allow --perm=relabelto --source=restorecond_t" and got a very long list of allow rules. I'm not quite sure how those look in the source code, if all of them have been individually listed, of if they use some general attributes. But obviously it's not completely wildcarded.
Is this a bug or a feature? :-)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/05/2011 04:39 PM, Göran Uddeborg wrote:
When using the Nvidia proprietary drivers, the files /dev/nvidiaN and /dev/nvidiactl don't get the right context. That has been discussed here and elsewhere previously. As I've understood it, it has to be fixed in the proprietary code somewhere.
To work around the problem until there is a proper fix, if ever, I added
/dev/nvidia0 /dev/nvidiactl
to /etc/selinux/restorecond.conf. But now I get a complaint about restorecond not being allowed to relabel those files:
type=AVC msg=audit(1312575006.803:33): avc: denied { relabelto } for pid=905 comm="restorecond" name="nvidiactl" dev=devtmpfs ino=18490 scontext=system_u:system_r:restorecond_t:s0 tcontext=system_u:object_r:xserver_misc_device_t:s0 tclass=chr_file
SEtroubleshoot suggests to audit2allow to make a module to allow that. I'll do that, so I can work around this problem too.
But I am a bit suprised by the need. Why isn't restorcond (or more properly, restorecond_t) allowed to relabel everything? Isn't that what it is all about?
I did a "sesearch --allow --perm=relabelto --source=restorecond_t" and got a very long list of allow rules. I'm not quite sure how those look in the source code, if all of them have been individually listed, of if they use some general attributes. But obviously it's not completely wildcarded.
Is this a bug or a feature? :-)
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
I would say it is a bug.
Daniel J Walsh:
On 08/05/2011 04:39 PM, Göran Uddeborg wrote:
Is this a bug or a feature? :-)
I would say it is a bug.
Then I'll provide a bugzilla so someone can have a look at it. :-)
selinux@lists.fedoraproject.org
-
Daniel J Walsh -
Göran Uddeborg