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

[David Herrmann]

Hi

>>> 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:
  pam_start(&pamh)
  pam_open_session(pamh)

and during shutdown:
  pam_close_session(pamh)
  pam_end(pamh)

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?

Thanks
David