[systemd-devel] Trivial denial of service using link to NFS mounted directory

Simon McVittie simon.mcvittie at collabora.co.uk
Mon Jul 1 04:06:50 PDT 2013

On 01/07/13 06:51, Andrey Borzenkov wrote:
> If symlink points to NFS (hard) mounted directory and NFS server is
> down, running "sysyemctl list-unit-files" result in systemd hanging and
> no more responding to anything.

What exactly do you mean by "symlink"? A symlink in a root-owned
directory like /etc/systemd/system or /lib/systemd/system?

If non-root users can't create this situation then it isn't a denial of
service. Root has much easier ways to break the system.

(If unprivileged users can write to /etc/systemd/system or
/lib/systemd/system, or to a file symlinked into one of those, then they
can already execute arbitrary code as root, so you've already lost.)

I would tend to consider this to be a flaw in NFS, more than in systemd:
NFS' usual failure mode is that I/O hangs forever. There isn't a great
deal that systemd can do about that: it could mitigate the problem in a
few specific situations by not re-reading files on disk, but that isn't
sufficient in general.

I suppose in principle systemd could avoid doing any I/O in process 1,
do all I/O in a subprocess and pass it to process 1 via some sort of
IPC... but that's a lot of complexity (= a lot of bugs) for a relatively
small benefit.


More information about the systemd-devel mailing list