[systemd-devel] logind and sessions tracking questions - (was: Debugging acl settings)

[Djalal Harouni]

Hi Coling,

Coling please I've some questions regarding what you have posted, see
below.

I'm trying to debug another bug in logind logic:
http://lists.freedesktop.org/archives/systemd-devel/2014-January/015968.html

I've located some bugs, I've a PoC version working, will post it but
first need to clear some points here to avoid breaking things.

On Mon, Jan 20, 2014 at 09:54:48AM +0000, 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:
Here I assume you are using a new systemd version (Fedora 20)? or
systemd from git?

I noticed in old systemd v204, the "Active" flag would be set to
"yes"  when we logout and the session keeps some programs running like
'screen'! I guess this also applies to gpg-agent...


> [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,
Please can you tell me about this last one "kill all processes" ?

How we set this flag? from my source code analysis I didn't found it and 
the new man page of pam_systemd does not show it:
http://www.freedesktop.org/software/systemd/man/pam_systemd.html
 
And I'm sure it was there at least for systemd 204!

> 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).
Hmm, ok this should be the default behaviour, I mean if processes are
not killed after logout then the session and user state files should not 
be removed and the state would be "closing"!


I've some notes about logind logic, I'll post them with the patches and
Cc'you

Thank you in advance Colin, I will Cc'you for pathes!

-- 
Djalal Harouni
http://opendz.org