'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/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@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@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