Bug#858807: /var/run/sshd should move to /run/sshd for stretch
Package: openssh-server
Version: 1:7.4p1-9
Severity: important
Hi,
the sshd process still puts the privilege separation directory in
/var/run/sshd. Since /var/run is symlinked to /run, this is fine in
the vast majority of cases. However, in rare cases where /var is on a
dedicated filesystem, it might be the case that /var is not yet fully
mounted when sshd is started.
Moving the privilege separation directory to /run fixes this issue at
least for ssh, which is important since one is able to fix other
things on the system once one is able to log in.
I therefore believe that this trivial change should be in stretch.
Long version (including a bit of systemd ranting, excuse me for that):
(1)
Before systemd, an early init script would issue a mount -a call which
in turn mounted all file systems marked auto in /etc/fstab and only
returned when all possible mounts completed. A failed mount of a
single file system resulted in a failed mount but allowed the boot to
continue, which frequently resulted in a crippled system, but one that
could be logged into even from remote to fix things.
(2)
systemd's default behavior is to stop the boot process once a single
filesystem fails to mount, which needs (a) access to the console of
the system which might be time-consuming and expensive in the case of
a headless server in a datacenter and (b) the root password to fix
things, which might be hard to obtain. A lot of companies keep the
root passwords of the servers in a safe or divided between two people,
one of them at manager level, which need to be called up to get access
to the root password. In those situations, root access for the admins
is usually obtained with sudo after a normal login. Therefore, needing
the root password to handle a thing as simple as a failed mount is bad.
(3)
If the "nofail" option is set on the fstab entry, the hard dependency
of local-fs.target to, for example, var.mount is relaxed. While this
is frequently mistaken as what an admin wanting to get (1) behavior
back wants, it actually does make the system not even wait for the
mount to complete before the boot continues. In the /var case, this
leads to systemd-tmpfiles-setup.service creating /var/run/sshd on the
mount point, which is over-mounted by the actual /var a second later,
which in turn has the /var/run => /run symlink with /run/sshd missing,
resulting in a systemd that cannot be logged in to because sshd is
missing its privilege separation directory.
Since there is currently no way to take a decision other than (2) or
(3) short of moving /var to the root file system, ssh should be using
/run instead of /var/run in the first place.
Thanks for considering.
Greetings
Marc
Reply to: