[systemd-devel] The whole su/pkexec session debate

[Colin Guthrie]

Hi,

One other thing occurred this morning while pondering the latest patches
from Martin and Colin on this topic.

What should (in an ideal world) apps like screen do?

I have a screen session on my server running a little python irc bot.

I ssh in to the server, start screen, start my bot, detatch and log out.

In so doing I get the following:

[colin at summit ~]$ loginctl session-status c2
c2 - colin (603)
           Since: Tue, 2013-11-19 19:57:40 GMT; 14h ago
          Leader: 3638
          Remote: jimmy.brent.tribalogic.net
         Service: sshd; type tty; class user
           State: closing
          CGroup: name=systemd:/user/colin/c2
                  ├ 3686 gpg-agent --keep-display --daemon
--write-env-file /home/colin/.gnupg/gpg-agent-info
                  ├ 3790 SCREEN
                  ├ 3791 /bin/bash
                  ├ 3849 /usr/bin/python /usr/bin/supybot tribabot.conf
                  └ 3853 /usr/bin/python /usr/bin/supybot tribabot.conf


The gpg-agent notwithstanding, the session state really shouldn't be
"closing". Well, it arguably *should* be closing, but my screen should
really be in an open session of it's own shouldn't it?

How do we fix this?

In this case, the session shouldn't really be nested (like in the case
of a su session - it arguably should be nested on top of the user
session which ran the su (thus killing the user session would also
propagate and kill the su session).

But in the case of screen I'm specifically asking for a new, stand alone
session. I want it to escape the current session and create a new one
(this would be true if I were to first create a nested session by
su'ing, then start screen as root - I think it should break out and
create a new top-level session for root).


Perhaps this is all OK, and the "closing" state here is not a problem.
But such apps and use cases really are not compatible at all with the
kill-session-processes= option of pam_systemd and it would be nice to do
things properly.

What's the right way forward?


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/