[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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                                       [cjwatson@debian.org]


Reply to: