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

David Herrmann dh.herrmann at gmail.com
Sun Dec 1 07:57:44 PST 2013


>>> But in the case of screen I'm specifically asking for a new, stand alone
>>> session.
>> I'd agree; but the fix would be fairly invasive for screen.  I think
>> it'd have to become setuid root, so it could request a new session.
> Yeah that was my fear too.
> Although perhaps this is just something that can be done via policy -
> e.g. perhaps screen can just ask logind to create a new session for us
> and then running some specific shell therein (i.e. a
> screen@$newsid.service) then immediately attaching to it.
> Perhaps this just needs something to control whether or not it's allowed
> to ask logind for a shell. This can perhaps be something controlled by
> system policy - e.g. you may be allowed but have to enter your password
> again, or you may just be allowed without further auth.
> I think eventually the semantics could be quite nice and could
> potentially avoid the need for setuid but I don't really know the extent
> of the needed infra here.

Screen can be fixed to call:

and during shutdown:

This way, screen will keep an "active" reference to the session and
systemd-logind will not mark it as "closing". So the session that was
initiated by sshd will be kept open by "screen". Note that
pam_open_session() without pam_authenticate() will *not* create a new
session but only attach to the current session.

I know, people often complain that they cannot spawn new sessions from
within an existing session, but I haven't seen any compelling argument
why it's needed. Are there other use-cases I'm not aware of?


More information about the systemd-devel mailing list