Re: [systemd-devel] Debugging acl settings for /dev//snd/pcm* nodes
'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@jimmy code (master)]$ udevadm info /dev/snd/pcmC0D0p P: /devices/pci:00/:00:1b.0/sound/card0/pcmC0D0p N: snd/pcmC0D0p E: DEVNAME=/dev/snd/pcmC0D0p E: DEVPATH=/devices/pci:00/: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@jimmy code (master)]$ loginctl SESSIONUID USER SEAT 1603 colinseat0 20603 colinseat0 I seem to have two sessions here. I'll look a the first one: [colin@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@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@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
Re: [systemd-devel] Debugging acl settings for /dev//snd/pcm* nodes
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@jimmy code (master)]$ udevadm info /dev/snd/pcmC0D0p P: /devices/pci:00/:00:1b.0/sound/card0/pcmC0D0p N: snd/pcmC0D0p E: DEVNAME=/dev/snd/pcmC0D0p E: DEVPATH=/devices/pci:00/: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@jimmy code (master)]$ loginctl SESSIONUID USER SEAT 1603 colinseat0 20603 colinseat0 I seem to have two sessions here. I'll look a the first one: [colin@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@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@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.
[systemd-devel] Debugging acl settings for /dev//snd/pcm* nodes
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. Thanks Regards, Hans ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Debugging acl settings for /dev//snd/pcm* nodes
'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@jimmy code (master)]$ udevadm info /dev/snd/pcmC0D0p P: /devices/pci:00/:00:1b.0/sound/card0/pcmC0D0p N: snd/pcmC0D0p E: DEVNAME=/dev/snd/pcmC0D0p E: DEVPATH=/devices/pci:00/: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@jimmy code (master)]$ loginctl SESSIONUID USER SEAT 1603 colinseat0 20603 colinseat0 I seem to have two sessions here. I'll look a the first one: [colin@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@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@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/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Debugging acl settings for /dev//snd/pcm* nodes
On Mon, Jan 20, 2014 at 9:42 AM, Hans de Goede hdego...@redhat.com wrote:
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.
There are udev rules adding a tag to the devices which should get ACLs attached:
/usr/lib/udev/rules.d/70-uaccess.rules
TAG+=uaccess
After device processing, the tags end up in the udev database:
$ udevadm info /sys/class/sound/controlC0 | grep TAGS
E: TAGS=:uaccess:
Private implementation details, never read directly, but useful for debugging:
$ grep G: /run/udev/data/c116\:10
G:uaccess
$ ls -1 /run/udev/tags/uaccess/
c10:232
c10:58
c116:10
...
During rules processing udev calls internally:
/usr/lib/udev/rules.d/73-seat-late.rules
RUN{builtin}+=uaccess
which actually adds the ACLs directly in the hotplug path.
At login/logout time, pam_systemd calls out to systemd-logind, logind
reads the above tags directory (with libudev) and applies/removes ACLs
to all devices with the uaccess tag.
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
