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

[Lennart Poettering]

On Thu, 27.03.14 05:18, Michael Biebl (mbiebl at gmail.com) wrote:

> 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.

Indeed. Fixed.

> 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)

True. Fixed too!

Please test!

Lennart

-- 
Lennart Poettering, Red Hat