[systemd-devel] simple way to crash systemd via a dangling symlink

[Michael Biebl]

There is an interesting bug which can be used to crash systemd via a
dangling symlink. For details please see [0].

To trigger the bug, you need a socket activated service. I'm using
cups in this case.

The steps to reproduce are
a/ Make sure cups.socket is properly configured and in state active (listening)
b/ Make sure cups.service is *not* running
c/ Create /etc/systemd/system/cups.socket.conf.d/ and then a dangling
symlink like this ln -s /nonexistent
/etc/systemd/system/cups.socket.conf.d/foo.conf
d/ Run systemctl daemon-reload
   The socket is now in this state:
   Active: active (listening)
   Loaded: error (Reason: No such file or directory)
e/ Now trigger a request on the cups.socket, e.g. using lpq
   → systemd freezes

The problem afaics is triggered in src/core/socket.c:
socket_enter_running(), when the incoming request causes the start of
the corresponding service unit via
r = manager_add_job(UNIT(s)->manager, JOB_START, UNIT_DEREF(s->service),
JOB_REPLACE, true, &error, NULL);

I think after the socket configuration has been messed up and the
daemon-reload, UNIT_DEREF(s->service) does no longer point to a valid
unit, and so the assert in manager_add_job() kicks in.

I tested this with 204 and 208, and both versions are affected.

Any suggestions how to fix this?

A few remarks
1/ A dangling drop-in snippet should imho *not* cause the unit Load state to be
Loaded: error (Reason: No such file or directory)
2/ If a socket is in such a state, we probably shouldn't process
incoming requests and try to start the service
3/ Should we stop the socket if the Load state is "error"

Michael

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742322#58

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?