Shouldn't restorecond be allowed to relabel anything?

[Göran Uddeborg]

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? :-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/selinux/attachments/20110805/7497b647/attachment.bin