Bug 150462

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* ???

[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.

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? =(

What about using pam_console for this?
It should be enough to add entry for this into the /etc/security/console.perms.

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"

This helps with the bug 150462 - at least for me.

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?

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.

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 ?

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.

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.

666 is nothing new.  We've been shipping Fedora this way for ages.

so ? Until I see reasons otherwise, that means "We've been insecure for ages"

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)

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

ok. so lets move on, and get it back to 0666.
Looks like a trivial udev fix.

Fixed in FC4.  We need to issue the udev update in FC3 updates before
the 2.6.11 kernel.

its been in fc3-updates-testing for a few days now.

Pushed to updates a while ago.  Closing.