HAL does not apply ACL on DRM device

Bug #306014 reported by Albert Damen on 2008-12-07
26
This bug affects 3 people
Affects Status Importance Assigned to Milestone
HAL
Fix Released
Medium
hal (Ubuntu)
Critical
Unassigned

Bug Description

libdrm 2.4.1 in Jaunty is configured with --enable-udev, so the device node /dev/dri/card* now is created via udev and patch 01_default_perms.diff does not help to set the right permissions anymore.
Therefore /dev/dri/card0 now gets file permissions crw-rw----. This results in poor performance, for example in sauerbraten and glxgears. Changing the permissions to 666 gives the old performance again.

On my system I have created the file /etc/udev/rules.d/45-dev-dri-permissions.rules with the line:
KERNEL=="card[0-9]", MODE="0666"

to automatically give /dev/dri/card0 the right permissions.

I think either a rule like that must be shipped in libdrm2 or a similar rule must be added to /etc/udev/rules.d/40-permissions.rules in udev.

Please note:
Section "DRI"
 Mode 0666
EndSection
in xorg.conf does not work anymore to set the permissions (see bug 303011).

libdrm2 2.4.1-0ubuntu7
kernel 2.6.28-2-generic, amd64

[workaround]
In /usr/share/hal/fdi/policy/10osvendor/20-acl-management.fdi replace the line:

  <merge key="access_control.file" type="copy_property">input.device</merge>

with:

  <merge key="access_control.file" type="copy_property">linux.device_file</merge>

Timo Aaltonen (tjaalton) wrote :

The group owner is 'video', and all users on my system belong to that group. What does it show for you?

Changed in libdrm:
status: New → Incomplete
Bryce Harrington (bryce) wrote :

Could you check if your user account is in the 'video' group? Timo and I wonder if the reason we didn't see it is because our accounts are in that group, so the permissions seem to be ok for us.

Timo Aaltonen (tjaalton) wrote :

fedora doesn't ship a ruleset either:

08:48 < airlied> tjaalton: I found a bug in hal acl setting
08:49 < airlied> tjaalton: the device perms shouldn't be set by X, either hal pam should do it.
08:49 < airlied> otherwise don't enable udev

(that's probably 'hal OR pam')

Changed in libdrm:
status: Incomplete → Confirmed

Created an attachment (id=20903)
hal-device output

This bug was originally reported in Ubuntu at launchpad: https://bugs.launchpad.net/ubuntu/+source/hal/+bug/306014

hal version: 0.5.12~rc1
Ubuntu Jaunty (development release)

In Ubuntu performance of 3D graphics, like glxgears, has dropped significantly with libdrm 2.4.1. Investigation showed I did not have rw access to the DRM device /dev/dri/card0. Access rights were crw-rw----, owner root, group video.
I am not a member of the video group.

However, HAL is supposed to set an ACL on the DRM device. getfacl showed this was not done successfully.
$ sudo getfacl /dev/dri/card0
getfacl: Removing leading '/' from absolute path names
# file: dev/dri/card0
# owner: root
# group: video
user::rw-
group::rw-
other::---

Policy-kit showed console and active console should get access to the DRM device.
Console-kit showed a valid session for me.

Attached is the output of hal-find-by-capability --capability drm | xargs hal-device

/usr/share/hal/fdi/policy/10osvendor/20-acl-management.fdi contains:
    <match key="info.capabilities" contains="drm">
        <append key="info.capabilities" type="strlist">access_control</append>
        <merge key="access_control.file" type="copy_property">input.device</merge>
        <merge key="access_control.type" type="string">video</merge>
    </match>

(I found the same lines on git).
However, hal-device does not list the property input.device, so apparently the key access_control.file could not be set.

Replacing:
<merge key="access_control.file" type="copy_property">input.device</merge>
by:
<merge key="access_control.file" type="copy_property">linux.device_file</merge>

solved the problem for me. Now the ACL was applied and performance was back to normal:
$ sudo getfacl /dev/dri/card0
getfacl: Removing leading '/' from absolute path names
# file: dev/dri/card0
# owner: root
# group: video
user::rw-
user:albert:rw-
group::rw-
mask::rw-
other::---

I have an Intel GM965 Integrated Graphics Controller, pci-id 8086:2a02.
Kernel is 2.6.28-2-generic (based on 2.6.28-rc7). I got the same results with an older kernel, 2.6.27-7-generic.

NB: libdrm 2.4.1 is the first version in Ubuntu using udev. Older versions set permissions on /dev/dri/card0 in a different way.

I am not a member of group video:
$ groups
albert adm dialout cdrom plugdev lpadmin admin sambashare

(first user on the system, installed from intrepid live cd, upgraded to jaunty)

Then for the hal acl:
- polkit-gnome-authorization shows console and active console should have access to Video Devices
- console-kit knows my session:
$ ck-list-sessions
Session2:
 unix-user = '1000'
 realname = 'Albert,,,'
 seat = 'Seat1'
 session-type = ''
 active = TRUE
 x11-display = ':0'
 x11-display-device = '/dev/tty7'
 display-device = ''
 remote-host-name = ''
 is-local = TRUE
 on-since = '2008-12-08T10:58:03.416594Z'
 login-session-id = '4294967295'
- but there is no acl on /dev/dri/card0:
$ sudo getfacl /dev/dri/card0
getfacl: Removing leading '/' from absolute path names
# file: dev/dri/card0
# owner: root
# group: video
user::rw-
group::rw-
other::---

note, for kvm I do get an additional line with getfacl: user:albert:rw-

Attached is the output of hal-find-by-capability --capability drm | xargs hal-device

Comparing the hal-device output to kvm, the key "access_control.file" seems to be missing?
/usr/share/hal/fdi/policy/10osvendor/20-acl-management.fdi contains:
    <match key="info.capabilities" contains="drm">
        <append key="info.capabilities" type="strlist">access_control</append>
        <merge key="access_control.file" type="copy_property">input.device</merge>
        <merge key="access_control.type" type="string">video</merge>
    </match>

I guess as the drm device has no key input.device, the key access_control.file is not properly set?

Albert Damen (albrt) wrote :

In /usr/share/hal/fdi/policy/10osvendor/20-acl-management.fdi I replaced the line:
<merge key="access_control.file" type="copy_property">input.device</merge>

by:
<merge key="access_control.file" type="copy_property">linux.device_file</merge>

After a reboot, I got access to /dev/dri/card0 and graphics performance was back at normal.

~$ sudo getfacl /dev/dri/card0
getfacl: Removing leading '/' from absolute path names
# file: dev/dri/card0
# owner: root
# group: video
user::rw-
user:albert:rw-
group::rw-
mask::rw-
other::---

Timo Aaltonen (tjaalton) wrote :

Cool, looks like you found the problem.

Changed in hal:
importance: Undecided → High
Albert Damen (albrt) wrote :

http://cgit.freedesktop.org/hal/tree/fdi/policy/10osvendor/20-acl-management.fdi shows the same lines for the DRM device. Forwarded upstream.

Changed in hal:
status: Unknown → Confirmed
Bryce Harrington (bryce) on 2008-12-09
description: updated
FriedChicken (domlyons) wrote :

Thank you, editing the fdi-file helped me, although the intel driver in Jaunty still seems to be a bit slow.

Bryce Harrington (bryce) wrote :

With no access to DRI, it can cause serious performance issues, such as measured in this article:
http://www.phoronix.com/scan.php?page=article&item=intel_graphics_q408

Changed in hal:
importance: High → Critical
milestone: none → jaunty-alpha-3
status: Confirmed → Triaged
FriedChicken (domlyons) wrote :

This bug is marked as "affects hal" but wouldnt it be a better solution to solve this on a lower leavel by udev?

FriedChicken (domlyons) wrote :

The given workaround (and also "sudo glxgears") produces rendering errors: glxgears overdraws windows lying over glxgears. So DRI seems to be defect in some way, but I'm not sure if this is related to this bug.

Daniel Queirolo (danf-1979) wrote :

I am member of the video group, and this bugged affected me too.

author Martin Pitt <email address hidden> 2009-01-19 11:08:59 (GMT)
committer Martin Pitt <email address hidden> 2009-01-19 11:08:59 (GMT)
commit 93c3cff6ed9ce7378aa37ead8b37e0bc837d6bc0

fix auto ACL management for DRI

Fix copy&paste error which assigned the wrong access_control.file for /dev/drm/card* devices. It previously copied "input.device", but should be "linux.device_file".

Albert Damen (albrt) wrote :

Fixed in:

hal (0.5.12~rc1-0ubuntu6)

    * Add 00git_fix_drm_acls.patch: Fix copy&paste error which assigned
       the wrong access_control.file for /dev/drm/card* devices. It
       previously copied "input.device", but should be
       "linux.device_file". This brings back hardware GL rendering,
       instead of always using the Mesa software rasterizer. (Part of
       LP #269509)

Changed in hal:
status: Triaged → Fix Released
Changed in hal:
status: Confirmed → Fix Released
nbubis (nbubis) wrote :

the above fix doesn't work for me - still no non-root permissions for /dev/dri/card*.

I'm running hal (0.5.12~rc1+git20090120-0ubuntu1) on a fresh Jaunty install and the line:

"<merge key="access_control.file" type="copy_property">linux.device_file</merge>"

already appears in "/usr/share/hal/fdi/policy/10osvendor/20-acl-management.fdi"

Of course if I manually change permissions and do a "kill -9 -1" then I get hardware rendering working until the next reboot.

Changed in hal:
importance: Unknown → Medium
Changed in hal:
importance: Medium → Unknown
Changed in hal:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.