Bug 87603

Summary:	systemd pid 1 breaks after receiving sigquit
Product:	systemd	Reporter:	Konstantin Gribov <grossws>
Component:	general	Assignee:	systemd-bugs
Status:	RESOLVED NOTABUG	QA Contact:	systemd-bugs
Severity:	critical
Priority:	medium	CC:	grossws
Version:	unspecified
Hardware:	x86-64 (AMD64)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:

Description Konstantin Gribov 2014-12-22 17:59:47 UTC

Component: systemd pid 1

OS: centos 7.0

Summary: systemd --system dbus interface not working after systemd received SIGQUIT (3) from root.

E. g. `kill -SIGQUIT 1` by root leads to logging something like this:

Dec 22 20:31:39 test systemd[1]: Caught <QUIT>, dumped core as pid 3871.
Dec 22 20:31:39 test systemd[1]: Freezing execution.


After that `systemctl` is useless since systemd isn't responding to dbus interface:

[root@test ~]# systemctl reboot
Failed to get D-Bus connection: Failed to connect to socket /run/systemd/private: Connection refused

Also, `reboot` doesn't work:

[root@test ~]# reboot
Failed to open /dev/initctl: No such device or address
Failed to talk to init daemon.


Reproduce: run `kill -SIGQUIT 1` under root.

Env: 
- Linux test 3.10.0-123.9.3.el7.x86_64 #1 SMP Thu Nov 6 15:06:03 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
- systemd-208-11.el7_0.5.x86_64

See also: https://gist.github.com/grossws/545fdcbc2c5d2703c89c

Comment 1 Dave Reisner 2014-12-22 18:24:29 UTC

By comparison:

sysvinit: doesn't catch/ignore SIGQUIT
upstart: doesn't catch/ignore SIGQUIT
openrc: catches SIGQUIT and then aborts

I don't think systemd needs to change its behavior here. Doing this is already a privileged operation, and as such, there's limitless other ways of shooting yourself in the foot as well.

Comment 2 Lennart Poettering 2014-12-22 18:26:21 UTC

Well. And why precisely is that a problem? I mean, you had priviliges and asked systemd to die while coredumping, and that's precisely what it did. if you don't want it to die and coredump don't send a sigquit...

Note that only sufficiently privileged processes can issue the sigquit hence there's no security problem here.

Comment 3 Konstantin Gribov 2014-12-22 19:11:13 UTC

As I see in http://svn.savannah.nongnu.org/viewvc/sysvinit/trunk/src/init.c?annotate=159&root=sysvinit (around line 1146) sysvinit set SIG_IGN for SIGQUIT. 

It seems that OpenRC isn't an init (it provides rc but not /sbin/init), so it's behavior depends on underlying sysvinit/bsd-init.

I don't see any SIGQUIT handler in upstart (and libnih), so it should behave like systemd, with pid 1 core dumped and broken system after `kill -SIGQUIT 1`.

It's not a security problem, of course. It's at most an usability problem. Is default core dump required for debugging systemd? Is there any reason not to ignore it?

Comment 4 Lennart Poettering 2014-12-23 02:02:24 UTC

(In reply to Konstantin Gribov from comment #3)
> As I see in
> http://svn.savannah.nongnu.org/viewvc/sysvinit/trunk/src/init.
> c?annotate=159&root=sysvinit (around line 1146) sysvinit set SIG_IGN for
> SIGQUIT. 
> 
> It seems that OpenRC isn't an init (it provides rc but not /sbin/init), so
> it's behavior depends on underlying sysvinit/bsd-init.
> 
> I don't see any SIGQUIT handler in upstart (and libnih), so it should behave
> like systemd, with pid 1 core dumped and broken system after `kill -SIGQUIT
> 1`.
> 
> It's not a security problem, of course. It's at most an usability problem.
> Is default core dump required for debugging systemd? Is there any reason not
> to ignore it?

Usability? I really don't see that. The usual expection on Unix is that SIGQUIT results in an abnormal process exit with a coredump. I really don't see why PID 1 should not support that too. It's not user-friendly to add different logic here to PID 1 without a really good reason for it.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.