Red Hat Bugzilla – Full Text Bug Listing
|Summary:||kernel-2.6.11-1.2_FC3 breaks DRI permissions?|
|Product:||[Fedora] Fedora||Reporter:||Warren Togami <wtogami>|
|Component:||udev||Assignee:||Harald Hoyer <harald>|
|Status:||CLOSED ERRATA||QA Contact:||Brian Brock <bbrock>|
|Version:||3||CC:||alan, davej, gajownik, harald, tmraz, wtogami, xgl-maint|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2005-03-29 02:41:45 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Warren Togami 2005-03-07 05:11:40 EST
kernel-2.6.10-1.770_FC3 crw-rw-rw- 1 root root 226, 0 Mar 6 23:45 /dev/dri/card0 kernel-2.6.11-1.2_FC3 crw-rw---- 1 root root 226, 0 Mar 6 23:59 /dev/dri/card0 FC3 fully updated userspace, logged into GNOME using my 'warren' account, somehow the new kernel's /dev/dri/card0 is 660 instead of 666. Everything except the kernel is unchanged. This is 100% reproducible rebooting between the two kernels. This makes no sense because the kernel does not control /dev. Huh? Environment: FC3 fully updated as of March 6th, 2005 udev-039-10.FC3.6 xorg-x11-6.8.1-12.FC3.21 IBM Thinkpad T41 Radeon 7500 with standard xorg.conf
Comment 1 Harald Hoyer 2005-03-07 05:33:24 EST
as it seems, udev creates this node with 0660. so, I should release udev-0.50, which has better handling of kernel 2.6.11 anyway. Do we really have to set 0666 with udev per default for /dev/dri/card* ???
Comment 2 Warren Togami 2005-03-07 05:42:15 EST
[root@ibmlaptop ~]# ls -l /dev/dri/card0 crw-rw---- 1 root root 226, 0 Mar 7 00:34 /dev/dri/card0 [root@ibmlaptop ~]# uname -a Linux ibmlaptop 2.6.11-1.2_FC3 #1 Sun Mar 6 23:05:05 EST 2005 i686 i686 i386 GNU/Linux [root@ibmlaptop ~]# rpm -q udev udev-050-8 Something is wrong. Upgraded to FC4's udev as suggested by harald, but permission is still bad.
Comment 3 Warren Togami 2005-03-07 05:51:15 EST
So the issue here is that 2.6.11 for the first time provides the sysfs udev stuff for DRI. Traditionally the permission of the DRI device was set by the X server by the below syntax in /etc/X11/xorg.conf. Section "DRI" Group 0 Mode 0666 EndSection Do we want udev to set the permission to 666 by default, or is it the X server's job? Isn't this a huge insecure mess and we're screwed no matter what we do? =(
Comment 4 Tomas Mraz 2005-03-07 07:18:29 EST
What about using pam_console for this? It should be enough to add entry for this into the /etc/security/console.perms.
Comment 5 Harald Hoyer 2005-03-07 07:32:43 EST
Also this may help: <mkearey> t8m There is a workaround already.. <mkearey> Section "Device" <mkearey> Identifier "Videocard0" <mkearey> Driver "radeon" <mkearey> VendorName "Videocard vendor" <mkearey> BoardName "ATI Radeon 9200" <mkearey> Option "DRI" "True" <mkearey> EndSection <mkearey> Option "DRI" "True"
Comment 7 Warren Togami 2005-03-07 13:52:43 EST
It would be preferable if we could issue this new kernel without breaking existing users by default. If this means issuing a new package of something else which changes the default, then we should do it. That is unless the X team says that Comment #5 is the only "correct" solution. If we can't come to any agreement on this quickly, can we temporarily rip out the new sysfs DRI stuff from the kernel while we come up with a better userspace solution for the long term? Bad idea?
Comment 8 Warren Togami 2005-03-07 15:57:08 EST
mharris has reminded me that permission 666 on /dev/dri/card* is NOT INSECURE. We only then need to come to an agreement of where to set the permission. The most logical place is udev's defaults. In any case this must be fixed before the FC3 update kernel, and we probably should fix this before FC4test1, otherwise DRI will be dead by default there too.
Comment 9 Dave Jones 2005-03-07 16:57:09 EST
it's not something worth holding up the release for test1 due to this. the only stuff that should block the release would be stuff that prevents users installing/updating. why is it not insecure ? Can it only be opened exclusively by one opener ?
Comment 10 Warren Togami 2005-03-07 17:08:09 EST
Sopwith said he considers this a bad for a release, because this isn't plain "DRI broken". Apps think DRI is available, but are denied and crash rather than fallback like if DRI were totally disabled. We should ship FC4test1 with a trivial fix in udev, 666 instead of 660, and agree on a long term plan (which may be the same thing) later.
Comment 11 Dave Jones 2005-03-07 17:16:48 EST
I'm still unclear on why this isn't insecure. I'd prefer to ship test1 with broken 3d than 'trivially exploitable by local users'. Also, if the apps crash instead of gracefully handling failure to open /dev/dri/cardX properly, they need fixing.
Comment 12 Warren Togami 2005-03-07 17:26:36 EST
666 is nothing new. We've been shipping Fedora this way for ages.
Comment 13 Dave Jones 2005-03-07 17:34:32 EST
so ? Until I see reasons otherwise, that means "We've been insecure for ages"
Comment 14 Mike A. Harris 2005-03-07 19:56:16 EST
In order for non-root to be able to use DRI, the permissions of the dri device node MUST be mode 0666. The DRI code itself manages who gets to do what with it. Read the DRI sources or DRI documentation for details. This is no more insecure than the X server socket being mode 0777. The security is handled inside the code rather than by the filesystem. Unless you have PROOF that there is an exploitable bug in DRI, you are operating on false pretenses by changing the mode to 0660. Do we make security changes because of REAL problems, or do we make random changes because we THINK THERE MIGHT be a problem now without actually researching it? Having said that though, when the bug reports start coming in that DRI no longer works, I'll gladly reassign all xorg-x11 bug reports that get filed to the kernel component. ;o)
Comment 15 Mike A. Harris 2005-03-07 20:41:30 EST
DRI/DRM security and locking documentation: http://dri.sourceforge.net/doc/security_low_level.html http://dri.sourceforge.net/doc/drm_low_level.html http://dri.sourceforge.net/doc/hardware_locking_low_level.html
Comment 16 Dave Jones 2005-03-08 02:56:57 EST
ok. so lets move on, and get it back to 0666. Looks like a trivial udev fix.
Comment 17 Warren Togami 2005-03-11 22:47:16 EST
Fixed in FC4. We need to issue the udev update in FC3 updates before the 2.6.11 kernel.
Comment 18 Dave Jones 2005-03-11 23:09:55 EST
its been in fc3-updates-testing for a few days now.
Comment 19 Warren Togami 2005-03-29 02:41:45 EST
Pushed to updates a while ago. Closing.