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

Tue Jan 21 06:38:01 PST 2014

Hi,

On 01/20/2014 10:54 AM, Colin Guthrie wrote:
> '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.

Thanks, very useful info. This seems to be caused by some of my own
changes to Xorg.

For those interested: It seems that the problem is that gdm starts
Xorg without a controlling tty, and some of the patches I've to make Xorg
run without root rights cause /dev/tty1 to no longer automatically become
the controlling tty of Xorg when it opens it.

And then "loginctl show-session" says:
VTNr=0
Active=no

And hence no acls on /dev/snd/pcm* (and others)

The problem is that Xorg needs to become session leader to get a controlling
tty assigned, but if it does that (by calling setsid) then if the tty is
already controlling another session it won't become Xorg's controlling tty
and Xorg cannot make various VT_FOO ioctls without root rights.

Anyways this is all fixable, just need to figure out how the various bits
will all work together here. FWIW this does not seem to be a systemd issue.

Regards,

Hans