'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/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. > > 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/ _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel