Bug 150462 - kernel-2.6.11-1.2_FC3 breaks DRI permissions?
kernel-2.6.11-1.2_FC3 breaks DRI permissions?
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: udev (Show other bugs)
3
All Linux
medium Severity medium
: ---
: ---
Assigned To: Harald Hoyer
Brian Brock
:
Depends On:
Blocks: FC3Update
  Show dependency treegraph
 
Reported: 2005-03-07 05:11 EST by Warren Togami
Modified: 2007-11-30 17:11 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-03-29 02:41:45 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
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 6 Tomas Mraz 2005-03-07 07:44:41 EST
This helps with the bug 150462 - at least for me.
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 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.

Note You need to log in before you can comment on or make changes to this bug.