[systemd-devel] Debugging acl settings for /dev//snd/pcm* nodes

[Colin Guthrie]

'Twas brillig, and Hans de Goede at 20/01/14 08:42 did gyre and gimble:
> Hi,
> 
> For some reason after I've built the Xorg xserver from git, and then login
> through gdm (on an otherwise unmodified F-20 install), the acls on
> /dev/snd/pcm* (and likely others too) no longer get setup to give the user
> I've just logged in with access to them.
> 
> Reverting to Xorg from the F-20 packages fixes this. I was wonder if
> someone
> could give a short step by step of all components involved in doing the acl
> management for devices which should be usable by console users now a days.
> 
> As well as some hints for debugging this.

Ultimately, the ACLs are applied to the active session to all device
nodes which have the uaccess tag.

e.g. on my machine:

[colin at jimmy code (master)]$ udevadm info /dev/snd/pcmC0D0p
P: /devices/pci0000:00/0000:00:1b.0/sound/card0/pcmC0D0p
N: snd/pcmC0D0p
E: DEVNAME=/dev/snd/pcmC0D0p
E: DEVPATH=/devices/pci0000:00/0000:00:1b.0/sound/card0/pcmC0D0p
E: MAJOR=116
E: MINOR=3
E: SUBSYSTEM=sound
E: TAGS=:uaccess:
E: USEC_INITIALIZED=62743


Notice the uaccess tag.

Ultimately this is applied to the "active" session, so you have to look
to loginctl:


[colin at jimmy code (master)]$ loginctl
   SESSION        UID USER             SEAT
         1        603 colin            seat0
        20        603 colin            seat0



I seem to have two sessions here. I'll look a the first one:

[colin at jimmy code (master)]$ loginctl show-session 1
Id=1
Timestamp=Thu 2014-01-16 12:34:44 GMT
TimestampMonotonic=41640698
VTNr=1
Display=:0
Remote=no
Service=gdm-password
Scope=session-1.scope
Leader=3563
Audit=1
Type=x11
Class=user
Active=no
State=closing
IdleHint=no
IdleSinceHint=1389896019397017
IdleSinceHintMonotonic=20376502012
Name=colin


OK, this one is NOT active and is closing. This is likely an older
session that has since been replaced after logging out and back in again
but it keeps some binaries running (likely gpg-agent stuff at a first
guess). Lets look:

[colin at jimmy code (master)]$ loginctl session-status 1
1 - colin (603)
           Since: Thu 2014-01-16 12:34:44 GMT; 3 days ago
          Leader: 3563
            Seat: seat0; vc1
         Display: :0
         Service: gdm-password; type x11; class user
           State: closing
            Unit: session-1.scope
                  ├─3647 ssh-agent
                  ├─3672 gpg-agent --daemon
                  ├─3889 /usr/bin/pulseaudio --start --log-target=syslog
                  ├─3898 /usr/libexec/pulse/gconf-helper
                  └─6871 gpg-agent --keep-display --daemon
--write-env-file /root/.gnupg/gpg-agent-info


Yup, in this case, I have my ssh-agent, gpg-agent and PulseAudio
services all loaded under the previous session. They didn't timeout and
stop after my logout and as things are not setup to kill all processes,
the session stays around in it's closing state. This is, so far, not
overly surprising even if the whole situation there is a little messy
(having the "closing" session live on as a kind of expected thing).

Anyway, looking at session 20:

[colin at jimmy code (master)]$ loginctl show-session 20
Id=20
Timestamp=Thu 2014-01-16 18:15:14 GMT
TimestampMonotonic=20471336546
VTNr=1
Display=:0
Remote=no
Service=gdm-password
Scope=session-20.scope
Leader=17287
Audit=20
Type=x11
Class=user
Active=yes
State=active
IdleHint=no
IdleSinceHint=1390208956248075
IdleSinceHintMonotonic=138343463253
Name=colin


It IS active, and thus my ACLs should be in place.


To actually debug the process of the uaccess tag and the device
chowining etc. you'd have to look more into logind itself and perhaps
turn on systemd debugging to see what it says about it (that said, I'm
not sure what debug it actually shows about this operation).

Certainly if the above bits are all working OK, then you can start to
probe further. If you don't have an active session then this is likely
what's wrong. Note that logging in via a tty and using e.g. startx *can*
lead to this situation unless the VT is reused for X11 which is not the
default upstream behaviour AFAIK. Most downstreams patch this behaviour
in in some way however, but worth pointing out just in case that's
what's tripping you up.

HTHs

Col









-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/