[Pkg-systemd-maintainers] systemd support in openssh-server

[Russ Allbery]

Michael Biebl <biebl at debian.org> writes:
> Am 11.02.2014 00:32, schrieb Michael Biebl:

>> I also wonder why the following check was added:

>> ExecStartPre=/usr/bin/test -c /dev/null

>> Why is this needed? Seems rather odd to me. With devtmpfs being
>> mandatory (in systemd/udev) nowadays, /dev/null is guaranteed to exist.
>> Do you remember why this check was added? Afaics it doesn't seem
>> necessary anymore nowadays.

Hi Michael,

This was discussed earlier on one of the attached bug reports for the
systemd unit support, and Colin referred to the original bug:

    http://bugs.debian.org/369964

> If you really want to keep this check, you might consider using a
> Condition test [1] like this:

> [Unit]
> ConditionPathExists=/dev/null
> ...

> Granted, this doesn't check whether /dev/null is a character device. But
> it is a much more lightweight check (doesn't need to execute a binary)
> and I'm having a hard time finding a scenario where /dev/null is
> anything but a character device

As you can see from the above bug report, the problem was that /dev/null
existed but wasn't a character device, so this doesn't help the original
problem case.

I have actually had this happen to me before, although admittedly it was
twenty years ago and on Solaris rather than Linux.  Something deleted
/dev/null, and then some other program came along and redirected its
output to /dev/null, which created /dev/null as a normal file.  This
resulted, as you might imagine, in some very... strange behavior.  One of
the problems with /dev/null is that, given how many programs open
/dev/null for write as part of e.g. daemon setup, if it's ever deleted by
accident somehow it very quickly ends up being recreated as a regular
file.

This still feels like a weird edge case to me, and I'm not sure it's worth
checking for it in the unit file, but on the other hand I completely
understand Colin's conservatism in maintaining checks when converting
between init system configurations.  And sshd has a special security role
on most systems, so being particularly paranoid is not unreasonable.

-- 
Russ Allbery (rra at debian.org)               <http://www.eyrie.org/~eagle/>