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