Bug#832155: New ssh-session-cleanup.service kills ssh user session during upgrade
Am 24.07.2016 um 17:47 schrieb Colin Watson: > Compromise proposal: how about I make it do nothing if libpam-systemd is > installed (e.g. "ConditionPathExists=!/usr/share/pam-configs/systemd", > which is probably the simplest available check without needing to deal > with multiarch paths), in which case presumably the hack isn't needed? > (For backports to jessie, such a check would need to be deleted, unless > you plan to backport the ordering fix as requested above.) Counter-proposal: Add libpam-systemd as recommends and ship ssh-session-cleanup.service only as an example file. Add a section to README.Debian mentioning that libpam-systemd + UsePAM yes is highly recommended (for the reasons I mentioned). If people want to opt out of this proposed default configuration, they should enable the ssh-session-cleanup.service unit by copying it to /etc/systemd/system and running systemctl enable ssh-session-cleanup.service. This is something I could be ok with, as this would only affect users which explicitly decide to use a non-default configuration. Cheers, Michael P.S: I'm curious how this was supposed to work under sysvinit? I don't see any special code which kills SSH user sessions on shutdown, am I missing something? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#832155: New ssh-session-cleanup.service kills ssh user session during upgrade
On Sun, Jul 24, 2016 at 01:38:25AM +0200, Michael Biebl wrote: > I referenced in my other reply that the network.target ordering has just > been added recently (in v230). So it is possible that previously there > was still an issue on shutdown. This is fixed now. Do you plan to update jessie with this fix? I ask because I've had requests to make this openssh change available in jessie-backports. > Besides, there are many other reasons why you really want libpam-systemd > in combination with SSH. > You really want the user process be tracked as part of the user session, > so you can properly apply resource limits or safely kill user sessions. Sure. But non-systemd users don't need libpam-systemd at all in this case (I'm aware that there are other cases where they may do), and it's just noise for them; and in the case of a package such as openssh-server that's often installed on very minimal systems indeed, they may not previously have needed to deal with resolving libpam-systemd's dependencies. Unfortunately there's no good way to say "Depends: libpam-systemd, but only if systemd is pid 1". It's unfortunate that we don't have a good way to simply be able to assume that all systemd users have libpam-systemd installed, which is what I'd really prefer to be able to do here. > > I think I'll add a Recommends on it, but I really want > > openssh-server to be usable on very minimal systems, including those > > using other init systems, without having to deal with dependency > > strangenesses. > > Please disable the ssh-session-cleanup.service hack by default if you > don't want to remove it. Or better, ship it as an example file. Compromise proposal: how about I make it do nothing if libpam-systemd is installed (e.g. "ConditionPathExists=!/usr/share/pam-configs/systemd", which is probably the simplest available check without needing to deal with multiarch paths), in which case presumably the hack isn't needed? (For backports to jessie, such a check would need to be deleted, unless you plan to backport the ordering fix as requested above.) > I really don't what such service file be installed (and active) by > default on every system. People might see it and think it's actually ok > to apply such hacks. I'd be happy to add a warning comment to discourage that. The script is short enough that such a comment would be unlikely to be overlooked. -- Colin Watson [cjwat...@debian.org]
Bug#832155: New ssh-session-cleanup.service kills ssh user session during upgrade
Am 24.07.2016 um 17:47 schrieb Colin Watson: > On Sun, Jul 24, 2016 at 01:38:25AM +0200, Michael Biebl wrote: >> I referenced in my other reply that the network.target ordering has just >> been added recently (in v230). So it is possible that previously there >> was still an issue on shutdown. This is fixed now. > > Do you plan to update jessie with this fix? I can do that. Unfortunately I've already filed the jessie-pu bug for systemd a couple of hours ago (#832336, for 8.6), but I could update the pu request accordingly. I see what I can do, otherwise it will be in the next stable point release, i.e 8.7 > dependencies. Unfortunately there's no good way to say "Depends: > libpam-systemd, but only if systemd is pid 1". Right, we do not have conditional Depends. But since sysvinit-core is the only existing alternative in stretch, we could use Depends: libpam-systemd | sysvinit-core. It's slighly ugly but would probably do the trick. > It's unfortunate that we don't have a good way to simply be able to > assume that all systemd users have libpam-systemd installed, which is > what I'd really prefer to be able to do here. I am more and more inclined that we should simply make libpam-systemd a hard dependency of either systemd or systemd-sysv. >> Please disable the ssh-session-cleanup.service hack by default if you >> don't want to remove it. Or better, ship it as an example file. > > Compromise proposal: how about I make it do nothing if libpam-systemd is > installed (e.g. "ConditionPathExists=!/usr/share/pam-configs/systemd", > which is probably the simplest available check without needing to deal > with multiarch paths), in which case presumably the hack isn't needed? > (For backports to jessie, such a check would need to be deleted, unless > you plan to backport the ordering fix as requested above.) I'm still pretty much convinced that a hack like this should not be shipped by default, which is totally unnecessary for a default installation. It set's a wrong precedent. If we start piling up hacks like this, in 10 years we are back at that mess that sysvinit has become. Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#832155: New ssh-session-cleanup.service kills ssh user session during upgrade
On Sun, 2016-07-24 at 01:38 +0200, Michael Biebl wrote: > It doesn't help for the non-systemd case and people who opt to not > install recommends by default use a non-standard configuration, so > it's > imho ok if those need to also apply additional configuration in case > of > SSH. We should optimize for the common case. Why should OpenSSH depend on a package, which it doesn't strictly need (or am I wrong here?) in both cases, with and without systemd? Especially when that package pulls in quite some further stuff (including systemd), which would then all people not running systemd get? And if libpam-systemd is so important for running systemd, wouldn't be just better if systemd itself depends on it? Most people, including e.g. myself will have it anyway already since systemd packages recommend it. And could you please elaborate why the way with the session-cleaner is a hack? I mean ssh.service is, so to say, just the gatekeeper, and for the actual sessions we have individual processes, that are basically like their own independent daemons. They run alone are (and shouldn't be killed) if ssh.service gets killed. So it seems actually good design to have a unit which takes care of those services. Moreover, consider that you get a security update to ssh. One restarts it, which however affects only the "main" sshd and the session processes continue to run on (as it should be the case per default). But in case the security issue was so critical, that it's better to kill of all the ssh sessions immediately, it would be just nice to have a service that could be used for that (which would again be the ssh- session handler service). Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#832155: New ssh-session-cleanup.service kills ssh user session during upgrade
Am 23.07.2016 um 12:29 schrieb Colin Watson: > On Sat, Jul 23, 2016 at 01:35:04AM +0200, Michael Biebl wrote: >> the addition of ssh-session-cleanup.service in the latest upload [1] is >> imho a bad idea. It's an aweful hack and besides, it also kills your SSH >> sessions on upgrades (thus severity RC). >> >> The proper fix is to use libpam-systemd. This will register a proper >> session scope when users log in via SSH. Those session scopes are >> ordered against systemd-user-sessions.service which itself has a proper >> ordering against network.target. So those user session are stopped >> before the network stack is shutdown. >> >> Please drop ssh-session-cleanup.service again and simply add a >> dependency on libpam-systemd. It's the correct solution for this >> problem. > > While of course I have libpam-systemd installed on all my systems, I > really don't want to depend on it; besides, the original report had > people saying that they encountered occasional problems of sessions not > being cleaned up even with PAM configured and libpam-systemd installed > too. I referenced in my other reply that the network.target ordering has just been added recently (in v230). So it is possible that previously there was still an issue on shutdown. This is fixed now. Besides, there are many other reasons why you really want libpam-systemd in combination with SSH. You really want the user process be tracked as part of the user session, so you can properly apply resource limits or safely kill user sessions. I think I'll add a Recommends on it, but I really want > openssh-server to be usable on very minimal systems, including those > using other init systems, without having to deal with dependency > strangenesses. Please disable the ssh-session-cleanup.service hack by default if you don't want to remove it. Or better, ship it as an example file. I really don't what such service file be installed (and active) by default on every system. People might see it and think it's actually ok to apply such hacks. It doesn't help for the non-systemd case and people who opt to not install recommends by default use a non-standard configuration, so it's imho ok if those need to also apply additional configuration in case of SSH. We should optimize for the common case. Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#832155: New ssh-session-cleanup.service kills ssh user session during upgrade
On Sat, 2016-07-23 at 11:29 +0100, Colin Watson wrote: > While of course I have libpam-systemd installed on all my systems, I > really don't want to depend on it; besides, the original report had > people saying that they encountered occasional problems of sessions > not > being cleaned up even with PAM configured and libpam-systemd > installed > too. I'm pretty sure I had experienced that at least several times (and I've had libpam-systemd installed (and of course not disabled) all the times since the beginning I've switched to systemd). Since a while however, I generally saw this problem much more rarely, but this may be just because my sessions nowadays start to hang even "worse" because of these: https://bugzilla.mindrot.org/show_bug.cgi?id=2572 https://bugzilla.mindrot.org/show_bug.cgi?id=2573 Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#832155: New ssh-session-cleanup.service kills ssh user session during upgrade
On Sat, Jul 23, 2016 at 01:35:04AM +0200, Michael Biebl wrote: > the addition of ssh-session-cleanup.service in the latest upload [1] is > imho a bad idea. It's an aweful hack and besides, it also kills your SSH > sessions on upgrades (thus severity RC). > > The proper fix is to use libpam-systemd. This will register a proper > session scope when users log in via SSH. Those session scopes are > ordered against systemd-user-sessions.service which itself has a proper > ordering against network.target. So those user session are stopped > before the network stack is shutdown. > > Please drop ssh-session-cleanup.service again and simply add a > dependency on libpam-systemd. It's the correct solution for this > problem. While of course I have libpam-systemd installed on all my systems, I really don't want to depend on it; besides, the original report had people saying that they encountered occasional problems of sessions not being cleaned up even with PAM configured and libpam-systemd installed too. I think I'll add a Recommends on it, but I really want openssh-server to be usable on very minimal systems, including those using other init systems, without having to deal with dependency strangenesses. I didn't notice the session-killing on upgrade *from* this version though. Sigh. Will fix that, thanks! -- Colin Watson [cjwat...@debian.org]
Bug#832155: New ssh-session-cleanup.service kills ssh user session during upgrade
Hi Colin Am 23.07.2016 um 01:42 schrieb Michael Biebl: > See also the relevant upstream commit: > > https://github.com/systemd/systemd/commit/8c856804780681e135d98ca94d08afe247557770 > > This fix is part of v230. Before that, we had no proper ordering on > shutdown, so it was indeed possible that some user sessions were not > properly terminated before the network was stopped (as some users > reported) due to race conditions. Btw, if you have any systemd related questions, feel free to poke use via the pkg-systemd-maintainers@ mailing list (in CC). We are always happy to provide feedback/help. Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#832155: New ssh-session-cleanup.service kills ssh user session during upgrade
See also the relevant upstream commit: https://github.com/systemd/systemd/commit/8c856804780681e135d98ca94d08afe247557770 This fix is part of v230. Before that, we had no proper ordering on shutdown, so it was indeed possible that some user sessions were not properly terminated before the network was stopped (as some users reported) due to race conditions. Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
