[systemd-devel] Debugging acl settings for /dev//snd/pcm* nodes
Colin Guthrie
gmane at colin.guthr.ie
Wed Jan 22 01:35:49 PST 2014
'Twas brillig, and Hans de Goede at 21/01/14 14:38 did gyre and gimble:
> 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.
Yup, that all seems quite logical. I've been following the
xorg-without-root stuff from a-far but am certainly interested to see it
land and make use of it :)
KUTGW!
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/
More information about the systemd-devel
mailing list