[Bug 465502] New: No 3D rendering or OpenGL with nVidia or ATI (fglrx) proprietary driver: permission problem
https://bugzilla.novell.com/show_bug.cgi?id=465502 Summary: No 3D rendering or OpenGL with nVidia or ATI (fglrx) proprietary driver: permission problem Classification: openSUSE Product: openSUSE 11.1 Version: RC 2 Platform: i686 OS/Version: openSUSE 11.1 Status: NEW Severity: Normal Priority: P5 - None Component: Hotplug AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: jimc@math.ucla.edu QAContact: qa@suse.de Found By: --- Created an attachment (id=264616) --> (https://bugzilla.novell.com/attachment.cgi?id=264616) Permission-granting script to go in /etc/ConsoleKit/run-session.d User-Agent: Opera/9.63 (X11; Linux i686; U; en) Presto/2.1.1 Build Identifier: My problem machines have the nVidia or ATI (fglrx) proprietary drivers for the graphics card. When a user logs in to the console, HAL, ConsoleKit, etc. give him ACLs allowing read/write access to many devices, but not to the graphics DRI interfaces: /dev/nvidia0, /dev/nvidiactl, /dev/dri/card0. Thus the user cannot do 3D rendering, and OpenGL falls back to snail-like software (MESA) rendering. Key detail: both brain-damaged proprietary drivers fail to register themselves so as to appear in sysfs. If they did appear, and if they described themselves (PCI category keys?) as video devices, I'm sure HAL and ConsoleKit would grant permission for them. Reproducible: Always Steps to Reproduce: 1. Configure the graphics card using a driver that doesn't do sysfs. 2. Log in to the console as any nonprivileged user. 3. Run a graphics test such as glxgears. Note the slow speed. Actual Results: 3D rendering doesn't happen. "getfacl /dev/nvidia0" (or whichever device) shows that the console user lacks permission to write on the device. Expected Results: Awesomely fast graphics rendering :-) In OpenSuSE 10.3, which used resmgr, I had a rule file in /etc/resmgr.conf.d which did "ongrant video run /usr/local/sbin/resgrant" (and similarly for revoke); that script basically does "chmod $RES_USER $devices". Kay Sievert suggested that I could put a similar script (attached) into /etc/ConsoleKit/run-session.d ; I did so, and now the console user does get permission for the graphics devices. I understand the bad points of closed source software, and I understand the distro managers' justified preference to not get entangled with it. However, SuSE is not exactly as pure as the driven snow, allowing Adobe Acrobat, Helix Banshee and Shockwave (Adobe) Flash in the distro. I expect that a lot of users are going to blame the distro when their graphics cards, which work just fine in Windows, go into snail mode on Linux; in other words, this issue has to be dealt with. I suggest as a compromise a lightweight script like mine, which only takes action if the driver is brain-dead and fails to announce its existence to HAL. Certainly you'll want to make the script more distro-friendly, e.g. by getting the list of troublemaker devices from /etc/sysconfig/something. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=465502 User aorlovskyy@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=465502#c1 Alexander Orlovskyy <aorlovskyy@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED CC| |aorlovskyy@novell.com AssignedTo|bnc-team-screening@forge.pr |sndirsch@novell.com |ovo.novell.com | --- Comment #1 from Alexander Orlovskyy <aorlovskyy@novell.com> 2009-01-15 06:15:28 MST --- Stefan, can you comment on bug? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=465502 User sndirsch@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=465502#c2 Stefan Dirsch <sndirsch@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|sndirsch@novell.com |hmacht@novell.com --- Comment #2 from Stefan Dirsch <sndirsch@novell.com> 2009-01-15 06:29:31 MST --- I don't know *anything* about ConsoleKit. Thus reassigning to ConsoleKit maintainer. IIRC it's not possible for nvidia/fglrx driver to register in sysfs due to copyright issues in the kernel (I think GPL only symbols; I'm sorry, but I don't remember the defails). At least for the default user, which is added to video group, the driver should work nevertheless. Otherwise add your user to video group. You can do this also with a NIS user. Adding this script is probably a security risk. Thus I'm afraid it won't be accepted. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=465502 User lnussel@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=465502#c3 Ludwig Nussel <lnussel@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lnussel@novell.com AssignedTo|hmacht@novell.com |kasievers@novell.com --- Comment #3 from Ludwig Nussel <lnussel@novell.com> 2009-01-15 06:45:19 MST --- In principle ConsoleKit can be abused for something like that. I'd write the script slightly different though. For multi session/multi user support one would also need some kind of reference counting and actually use ACLs. IMHO ConsoleKit isn't the correct place to put this script though, some other package has to put it in place (e.g hal or the drivers themselves). Reassigning to Kay who seems to work on finding a common solution to such problems. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=465502 User kasievers@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=465502#c4 Kay Sievers <kasievers@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|Normal |Enhancement --- Comment #4 from Kay Sievers <kasievers@novell.com> 2009-01-15 07:04:37 MST --- (In reply to comment #2)
IIRC it's not possible for nvidia/fglrx driver to register in sysfs due to copyright issues in the kernel (I think GPL only symbols; I'm sorry, but I don't remember the details). That's correct.
(In reply to comment #3)
Reassigning to Kay who seems to work on finding a common solution to such problems. We are currently working on moving device-classification and ACL-management to udev, and a tool called udev-acl. But unfortunately this can not really work for stuff that does not show up in sysfs.
I guess putting the user in the "video" group as long as the proprietary drivers are used is the simplest solution for now. I'll check with the other involved people, if there are any plans supporting "broken" device nodes with ACL management, and how it would look like. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=465502 User jimc@math.ucla.edu added comment https://bugzilla.novell.com/show_bug.cgi?id=465502#c5 --- Comment #5 from James Carter <jimc@math.ucla.edu> 2009-01-15 10:50:14 MST --- @sndirsch & @kasievers: For a machine with one user or maybe a family, groupwise permission management is fine. But we manage an instructional program with four computing labs and about 1000 students (different every 3 months); an enterprise deployment would have similar problems. Putting every student in group "video" would likely exceed a buffer limit -- better to make /dev/nvidia0 mode 666. But these are undergraduates with too much time on their hands; I'm sure you get my drift here. We really want the console user, specifically, to have access. Granting permission via an ACL would be nice, but I wanted to keep it simple, and in particular, if the machine crashed with the ACL row in place, it takes a little brainpower to get rid of it next time around, particularly if it's possible that unrelated ACL rows (like for a global notification daemon) might be configured. Hell will freeze over before the vendors make their drivers' licenses FOSS compliant. Maybe a compromise: they would register with sysfs only the most basic device characteristics, bypassing legally troublesome proprietary features. But to really solve the problem is kind of off topic for this thread and will take until OpenSuSE 12.3 at least. "You guys got me to pay for these fancy cards which work fine in Windows, and now you tell me Linux can't handle them? You're all fired! And take your Linux crap with you." Pointy-haired bosses do say things like that. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=465502 User kasievers@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=465502#c6 --- Comment #6 from Kay Sievers <kasievers@novell.com> 2009-01-15 11:06:41 MST --- (In reply to comment #5)
@sndirsch & @kasievers: For a machine with one user or maybe a family, groupwise permission management is fine. But we manage an instructional program with four computing labs and about 1000 students (different every 3 months); an enterprise deployment would have similar problems. student in group "video" would likely exceed a buffer limit
That sound like NIS, LDAP like setups, which should be fine with such a group assignment. :)
better to make /dev/nvidia0 mode 666.
That's what most people do with these drivers, yes. But a distro can not do that by default for security reasons.
Granting permission via an ACL would be nice, but I wanted to keep it simple, and in particular, if the machine crashed with the ACL row in place, > it takes a little brainpower to get rid of it next time around
Changes in /dev do no survive a reboot, /dev is a tmpfs, populated from scratch at every reboot. Is that what you mean?
Hell will freeze over before the vendors make their drivers' licenses FOSS compliant. Maybe a compromise: they would register with sysfs only the most basic device characteristics, bypassing legally troublesome proprietary features.
It's only one driver they load, and as long as the driver does not advertise itself in the kernel as GPL, they can not see the needed functions, can not resolve the GPL symbols in the kernel. So they would need to change the whole driver, and publish parts of it to be able to do that. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=465502 User jimc@math.ucla.edu added comment https://bugzilla.novell.com/show_bug.cgi?id=465502#c7 --- Comment #7 from James Carter <jimc@math.ucla.edu> 2009-01-15 12:26:45 MST --- We use NIS, and will soon migrate to NIS emulation in LDAP. They do not have proper relational database tables; both are actually emulations of the original UNIX files. In other words, you can do getgrnam or getgrgid, and the NIS server has a Berkeley DB table for those keys, but the values are entire rows from the master group file. Still too long. We need to do this right, i.e. do what you suggested with a script in /etc/ConsoleKit/run-session.d. And the distro is very correct in not setting mode 666: permission too broad on the graphics device (like putting all the students in group video) invites pranks and FERPA violations. You're right, /dev is volatile in a reboot. I was thinking from the previous millenium. No more foot-dragging about ACLs. It's been a while since I looked at this, but some of the wireless drivers look like they have a FOSSoid top layer which acts as middleware to a separate driver that has the ugly parts. But that doesn't solve any problems for this quarter's students. I'm trying to influence the distro managers to come up with a semi-sanitary solution for this fairly common range of devices, so Linux will work out of the box for more users. That's the way to spread the gospel. Pressure on the vendors to FOSS-ize drivers is fine, but telling my mother-in-law to boycott nVidia is going to lead to her boycotting Linux instead, and similarly for the all-important corporate CIO. And I'm sure it was not the most productive use of your time to answer my query on this topic on ConsoleKit-devel; at least it's now in the mailing list archives. Thank you for effective help there. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com