Bug 241712

This looks like you have a badly mislabeled file system or something is going
very strange.

Running the avc messages you attached gives output 

allow udev_t etc_t:chr_file { create setattr };

Whic indicates udev is trying to create a chr_file in an etc directory?

I ran ls -Z /dev/nvidia0:

ls -Z /dev/nvidia0
crw-------  joel root system_u:object_r:xserver_misc_device_t /dev/nvidia0  

Running restorecon didn't change the label.  The Nvidia driver was working
without problems on FC6 running SELinux targeted.  After the upgrade to FC7 RC
2, I built the nvidia.ko module from the Livna SRPM.  /dev/nvidia0 has a date of
10 March, which is the date of xorg-x11-drv-nvidia-1.0.9755-2.lvn7.

Do you have any suggestions?  Relabeling the system?

I've also been getting this data from logwatch since the update from fc6:

 --------------------- Selinux Audit Begin ------------------------ 

 *** Denials ***
    system_u system_u (chr_file): 15 times
    system_u system_u (dir): 85 times
 
  Number of audit daemon starts: 5 
 
  Number of audit daemon stops: 5 
 
 ---------------------- Selinux Audit End ------------------------- 

I don't remember ever seeing selinux audit entries in logwatch before.

See if 

setsebool -P allow_execstack=1 

fixes your nvida problem.

Also please attach your audit.log

Created attachment 155713 [details]
Audit Log

Your suggestion didn't work:

[root@alcibiades audit]# setsebool -P allow_execstack=1
Could not change policy booleans

the nvidia driver needs a bunch of device files - /dev/nvidiactl and
/dev/nvidia[0-9] chiefly. Something stashes them in /etc/udev/devices, where (in
theory) udev copies them to /dev at startup. 

Perhaps this is udev trying to save these newly-created devices to
/etc/udev/devices?

Joel setsebool failed?  This seems like your machine is badly mislabeled.  Have
you triggered a relabel.  

touch /.autorelabel; reboot


Will the idea of /etc/udev/devices is probably correct.

I did a relabel last night.  It didn't help.

ls - Z /etc/udev/devices

crw-------  root root system_u:object_r:etc_t          nvidia0
crw-------  root root system_u:object_r:etc_t          nvidia1
crw-------  root root system_u:object_r:etc_t          nvidia2
crw-------  root root system_u:object_r:etc_t          nvidia3
crw-------  root root system_u:object_r:etc_t          nvidiactl

They've been there all along.  Their file dates are 10 March.

I'll try removing the nvidia rpms, relabeling, and then reinstalling them.

I removed the nvidia rpms, relabeled, reinstalled.  Same behavior, same messages.

The problem here is the labeling of the /etc/udev/devices directory. 

This directory should be labeled device_t and I bet it would work.  

You can create the directory
chcon -t device_t /etc/udev/devices 

But why is udev creating the devices in this directory at all rather then on /dev?

Udev isn't creating these devices -- they're included in the livna rpm:

[joel@alcibiades ~]$ rpm -ql xorg-x11-drv-nvidia-1.0.9755-2.lvn7
/dev/nvidia0
/dev/nvidia1
/dev/nvidia2
/dev/nvidia3
/dev/nvidiactl
/etc/ld.so.conf.d/nvidia.conf
/etc/modprobe.d/nvidia
/etc/profile.d/nvidia.csh
/etc/profile.d/nvidia.sh
/etc/rc.d/init.d/nvidia
/etc/udev/devices/nvidia0
/etc/udev/devices/nvidia1
/etc/udev/devices/nvidia2
/etc/udev/devices/nvidia3
/etc/udev/devices/nvidiactl

-- snip remainder of file listing --

I'll try your suggestion and see if it works.

That didn't work either.  Just after udev starts, I see the boot message:

cp:  cannot stat '/dev/nvidia0': permission denied.

Then the same lines for the other devices.

Then, I believe, cannot lstat /dev/nvidia0:  no such file or directory.

Once I've booted with enforcing=0, I can issue a setenforce 1 command and
everything seems to work just fine.

/etc/udev/devices is deprecated anyway. The "clean" way now would be
/etc/udev/makedev.d/60-nvidia.nodes and the nvidia rpm should also provide
/etc/makedev.d/60nvidia.

I just filed this at livna where it belongs (
http://bugzilla.livna.org/show_bug.cgi?id=1504 )

(In reply to comment #16)
> I just filed this at livna where it belongs (
> http://bugzilla.livna.org/show_bug.cgi?id=1504 )

Thanks for doing that.  I tried to create a bugzilla account at Livna yesterday,
but never got a confirmation email with a password.  They may still be having
problems related to their hard drive failure.

*** Bug 242102 has been marked as a duplicate of this bug. ***

*** Bug 242320 has been marked as a duplicate of this bug. ***

If you execute the following does everything work.  

#  chcon -t bin_t /sbin/start_udev

The startup script is labeled udev_exec_t and I believe this is incorrect.   If
we label it bin_t the startup will continue to run in initrc_t and will
transition to udev_t only when udev starts up.

If this does not work, we could also try to label /etc/udev/devices as device_t.

chcon -R -t device_t /etc/udev/devices

Livna has issued a new rpm consistent with Harald Hoyer's comment and the
problem now seems to be resolved, at least with respect to Livna.

*** Bug 242496 has been marked as a duplicate of this bug. ***