Re: [systemd-devel] The whole su/pkexec session debate
On Wed, 20.11.13 10:16, Colin Guthrie (gm...@colin.guthr.ie) wrote: 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 used to believe that screen should set up a new session, but I don't think so anymore. Nowadays think they should do exactly what they currently do: fork and stay around. This will cause the session to stay in closing state when the user logs out, but that's exactly what it would be good for: i.e. sessions which have officially finished but of which some parts remain. 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. If user session killing is enabled then this is explicitly supposed to be the admins way to prohibit things like screen if the user is not logged in otherwise. Hence I think the exact right thing happens already: if the admin doesn't want to allow screen to stay around then he can use that option. Otherwise he should leave it on. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] The whole su/pkexec session debate
On Wed, 20.11.13 09:49, Colin Walters (walt...@verbum.org) wrote: On Wed, 2013-11-20 at 10:16 +, Colin Guthrie wrote: How do we fix this? There are a lot of cases - screen is just one of them. I think to make forward progress on this we'll have to enumerate the cases, evaluate the problems with each, then for each problem, evaluate a fix - and make sure that fix doesn't regress one of the other cases. Fun! =) One very important thing that's in the mix here is the user@.service future. It helps us move forcefully away from the old model of independent sessions, a direction we've been going incrementally via additions of things like XDG_RUNTIME_DIR (and then higher level things on top like a per-user bus instead of per-session). Cron for example could be spawned from user@service. Note that user@.service actually can be made to stay around if user lingering is on (see loginctl enable-linger). The idea here is that allowing cronjobs and suchlike of the user while the user isn't actually logged in must be something that is explicitly enabled. And the the lingerng stuff is supposed to do that. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] The whole su/pkexec session debate
On Sun, 01.12.13 16:57, David Herrmann (dh.herrm...@gmail.com) wrote: 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) Actually it's more complicated. It would have to be privileged and fork once in the middle. And by default it pam_systemd would just make it a member of the original session again, hence to no effect. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] The whole su/pkexec session debate
On Mon, 02.12.13 10:00, Colin Guthrie (gm...@colin.guthr.ie) wrote: 'Twas brillig, and Martin Pitt at 02/12/13 05:48 did gyre and gimble: This way, screen will keep an active reference to the session and systemd-logind will not mark it as closing. But that screen process would still be running in the user's logind session cgroup, so logind can see that the session is still active that way? (Unless you configured it to kill all session processes on logout). The session is still marked as closing but because processes still exist it never quite dies. And yes, the kill processes option (which is a nice thing to enable if possible) would indeed kill the screen. It would be really nice if screen somehow escaped, but if the pam* calls need root then I think some other way would be better (perhaps with logind doing some of the setup work... dunno). I am pretty sure that screen should not get the right to escape here. It should be a program like any other, and if the admin decides to now allow people leaving processes around after logging out then screen should be killed, the same way as any other process. The kill-on-logout thing really is something that explicitly should kill screen too, otherwise it would not be so useful. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] The whole su/pkexec session debate
Lennart Poettering [2013-12-11 3:11 +0100]: I used to believe that screen should set up a new session, but I don't think so anymore. Nowadays think they should do exactly what they currently do: fork and stay around. This will cause the session to stay in closing state when the user logs out, but that's exactly what it would be good for: i.e. sessions which have officially finished but of which some parts remain. FWIW, I fully agree. I don't see anything what would make screen special. It does not even get close to the PAM stack, being concerned about users, etc. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] The whole su/pkexec session debate
Lennart Poettering [2013-12-11 3:17 +0100]: I am pretty sure that screen should not get the right to escape here. [..] The kill-on-logout thing really is something that explicitly should kill screen too, otherwise it would not be so useful. Not only not so useful, it would be rendered entirely useless as you can run any program in a screen shell. If you poke holes into that, the next person will come around and say but keep nohup, too, and so on. For desktops you usually want kill-on-logout configured off (at least if you expect your users to run things like screen, nohup, or plus disown), and if you turn it on in environments like coffee shops, school labs, or other public computers it should really kill everything, period. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] The whole su/pkexec session debate
Hi On Mon, Dec 2, 2013 at 8:17 PM, Colin Walters walt...@verbum.org wrote: On Mon, 2013-12-02 at 14:37 +0100, David Herrmann wrote: But then gnome-session should simply call ReleaseSession() on the bus itself.. I'd rather have some sort of API where a particular process is the session leader, and its exit implies closing. Something like a pid file in /run/systemd/sessions/c0/leader/pid which is owned by the session's uid/gid? There is no sane way to watch for specific childs in systemd-logind. We don't have a childfd(2) call or poll(2) on /proc/pid... So we usually just apply this policy on the first process in a session (which we get SIGCHLD for). Once it exists, we mark the session as closing. I think that's a good compromise. But for the ssh case we'd need something to inhibit this behavior. Like a bus call Session.KeepOpen() which keeps the session open until the caller closes the bus-connection. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] The whole su/pkexec session debate
On Mon, 2013-12-02 at 14:37 +0100, David Herrmann wrote: But then gnome-session should simply call ReleaseSession() on the bus itself.. I'd rather have some sort of API where a particular process is the session leader, and its exit implies closing. Something like a pid file in /run/systemd/sessions/c0/leader/pid which is owned by the session's uid/gid? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] The whole su/pkexec session debate
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@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/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] The whole su/pkexec session debate
On Wed, 2013-11-20 at 10:16 +, Colin Guthrie wrote: How do we fix this? There are a lot of cases - screen is just one of them. I think to make forward progress on this we'll have to enumerate the cases, evaluate the problems with each, then for each problem, evaluate a fix - and make sure that fix doesn't regress one of the other cases. Fun! =) One very important thing that's in the mix here is the user@.service future. It helps us move forcefully away from the old model of independent sessions, a direction we've been going incrementally via additions of things like XDG_RUNTIME_DIR (and then higher level things on top like a per-user bus instead of per-session). Cron for example could be spawned from user@service. 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. 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. I believe that option is not the default precisely because of screen. But anyways...we have to take some level of incrementalism here. Martin's patch is a very small and correct fix for a real-world problem. My patch is a bit more invasive, but I think it's going closer to the root of the problem. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] The whole su/pkexec session debate
Hi! 'Twas brillig, and Colin Walters at 20/11/13 14:49 did gyre and gimble: On Wed, 2013-11-20 at 10:16 +, Colin Guthrie wrote: How do we fix this? There are a lot of cases - screen is just one of them. I think to make forward progress on this we'll have to enumerate the cases, evaluate the problems with each, then for each problem, evaluate a fix - and make sure that fix doesn't regress one of the other cases. Fun! =) Yup! One very important thing that's in the mix here is the user@.service future. It helps us move forcefully away from the old model of independent sessions, a direction we've been going incrementally via additions of things like XDG_RUNTIME_DIR (and then higher level things on top like a per-user bus instead of per-session). ACK again. Cron for example could be spawned from user@service. 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. 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. I believe that option is not the default precisely because of screen. Makes sense. But anyways...we have to take some level of incrementalism here. Martin's patch is a very small and correct fix for a real-world problem. My patch is a bit more invasive, but I think it's going closer to the root of the problem. Absolutely. It is just nice to get an overview of the bigger picture here. Perhaps someone can start to write up a future of sessions wiki page with a few notes on what is needed going forward. Cheers 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/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
