From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041228 Firefox/1.0 Fedora/1.0-8 Description of problem: audit(1105622933.678:0): avc: denied { getattr } for pid=678 exe=/bin/cp path=/etc/udev/devices/nvidia0 dev=dm-0 ino=665505 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:etc_t tclass=chr_file audit(1105648170.174:0): avc: denied { unlink } for pid=2291 exe=/bin/rm name=nvidia0 dev=tmpfs ino=1991 scontext=system_u:system_r:sysadm_t tcontext=system_u:object_r:device_t tclass=chr_file audit(1105648170.188:0): avc: denied { create } for pid=2292 exe=/bin/mknod name=nvidia0 scontext=system_u:system_r:sysadm_t tcontext=system_u:object_r:device_t tclass=chr_file audit(1105648170.190:0): avc: denied { setattr } for pid=2293 exe=/bin/chmod name=nvidia0 dev=tmpfs ino=6016 scontext=system_u:system_r:sysadm_t tcontext=system_u:object_r:device_t tclass=chr_file Version-Release number of selected component (if applicable): selinux-policy-strict-1.21.1-1 How reproducible: Didn't try Steps to Reproduce: Additional info:
Also: xscreensaver denials on nvidiactl audit(1105658137.308:0): avc: denied { read write } for pid=4944 exe=/usr/libexec/xscreensaver/hacks/rubik name=nvidiactl dev=tmpfs ino=6040 scontext=user_u:user_r:user_t tcontext=system_u:object_r:xserver_misc_device_t tclass=chr_file audit(1105658137.308:0): avc: denied { ioctl } for pid=4944 exe=/usr/libexec/xscreensaver/hacks/rubik path=/dev/nvidiactl dev=tmpfs ino=6040 scontext=user_u:user_r:user_t tcontext=system_u:object_r:xserver_misc_device_t tclass=chr_file dev=tmpfs ino=6040 scontext=user_u:user_r:user_t tcontext=system_u:object_r:xserver_misc_device_t tclass=chr_file audit(1105669487.127:0): avc: denied { read write } for pid=5953 exe=/usr/libexec/xscreensaver/hacks/cage name=nvidiactl dev=tmpfs ino=6040 scontext=user_u:user_r:user_t tcontext=system_u:object_r:xserver_misc_device_t tclass=chr_file audit(1105669487.127:0): avc: denied { ioctl } for pid=5953 exe=/usr/libexec/xscreensaver/hacks/cage path=/dev/nvidiactl dev=tmpfs ino=6040 scontext=user_u:user_r:user_t tcontext=system_u:object_r:xserver_misc_device_t tclass=chr_file
Heh, I installed nvidia-glx and now I get 256 of the udev->etc_t denials. udev denials confirmed in enforcing mode.
This fixes some of the problems for me: --- start_udev.bak 2005-01-19 02:13:43.000000000 -0700 +++ start_udev 2005-01-19 03:25:04.000000000 -0700 @@ -55,7 +55,9 @@ echo net/tun ppp console null zero cpu/microcode; ); [ -a /dev/MAKEDEV ] || ln -s $MAKEDEV /dev/MAKEDEV; - cp -a /etc/udev/devices/* /dev/ >/dev/null 2>&1 || : + + cp -a /etc/udev/devices/* /$udev_root/ > /dev/null 2>&1 || : + restorecon /$udev_root/* > /dev/null 2>&1 || : fi } --- udev.old 2005-01-19 02:26:26.000000000 -0700 +++ udev.fc 2005-01-19 02:26:14.000000000 -0700 @@ -6,6 +6,7 @@ /usr/bin/udevinfo -- system_u:object_r:udev_exec_t /etc/dev\.d/.+ -- system_u:object_r:udev_helper_exec_t /etc/udev/scripts/.+ -- system_u:object_r:udev_helper_exec_t +/etc/udev/devices/.* system_u:object_r:device_t /etc/hotplug\.d/default/udev.* -- system_u:object_r:udev_helper_exec_t /dev/udev\.tbl -- system_u:object_r:udev_tbl_t /dev/\.udev\.tdb/.* -- system_u:object_r:udev_tdb_t I wanted to do restorecon on the devicies being copied only, but restorecon is absurdly slow when cycling over 256 nvidia cards. It's a lot faster when you invoke it once with args, but I don't think the shell will tolerate that many arguments. Consequences of restorecon on /dev: /dev/shm is restored from tmpfs_t to device_t every time. The xscreensaver problems are a different issue, and I will file a different bug for that.
You can pipe a list to restorecon cat /tmp/filelist | restorecon -v -f -
Is this the correct idea though? Restorecon when copying the device files? Perhaps you should fix start_udev somehow. I am having some trouble getting awk under control - I never really liked scripting.
Details...? why NOTABUG? Without doing *something* about the context of the files in /etc/udev/devices they end up having the wrong context when put in /dev. Now you could either restorecon /dev (as suggested), or you could store the correct contexts in /etc/udev/devices, and copy them, or something else....
I also wrote a patch that changed types.fc to label all files in /dev, /udev, and /etc/udev/devices identically using a macro. Then you could copy with the preserve context flag. It works well, but I thought it was the wrong thing to do at the time vs. a restorecon solution. If you're interested in that approach I can attach patch.
hmm, I would like to implement the restorecon. Btw, I "cp -a" which means "cp -dpR" which should preserve the context. So, if you setup the right contexts in /etc/udev/devices, then all should be fine.
What's the status of this bug? It has a simple resolution, so why is it not closed yet? All that's needed is an efficient call to restorecon on all the files installed in /dev by start_udev (one invocation, not one per device) Additionally, the file contexts for udev need to be patched to have the device_t type.
file context patch merged, only start_udev fix is left here.