HAL does not apply ACL on DRM device

[Albert Damen]

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)]

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

[Bryce Harrington (bryce)]

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)]

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')

[Albert Damen (albrt)]

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.

[Albert Damen (albrt)]

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)]

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)]

Cool, looks like you found the problem.

[Albert Damen (albrt)]

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

[FriedChicken (domlyons)]

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

[Bryce Harrington (bryce)]

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

[FriedChicken (domlyons)]

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)]

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)]

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

[Albert Damen (albrt)]

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)]

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)

[nbubis (nbubis)]

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.