Re: runit SIGPWR support

2020-02-28 Thread fungal-net
It might be plain ignorance on my side but is there a possibility
that some malicious outsider's intent be able to induce a SIGPWR
signal just to fool the system to shut down?  If so then hardcoding
it as an autoresponse would be perceived as a weakness.  The choice
for any sysadmin to use the kernel signal and direct it to any
designed chosen process is still open without it.


Re: runit SIGPWR support

2020-02-28 Thread Alex Suykov
Fri, Feb 28, 2020 at 07:39:47AM +0100, Jan Braun wrote:

> The Linux kernel uses SIGPWR to tell init "there's a power failure
> imminent". There's a difference to "please shutdown the system", even if
> (current versions of) busybox and openrc choose to shutdown the system
> when told about an imminent power failure.

The Linux kernel never sends SIGPWR to init on most platforms.

Grepping the source, there are only about two places where SIGPWR can be
sent to the init process from the kernel: machine check exception on S390,
and some power-related hardware failure indication on SGI workstations.
I'm not familiar with either of those but I suspect in both cases
the signal is expected to initiate immediate shutdown. Otherwise, why
would they signal init.

Just for reference, I checked apcupsd sources. It does include an example
of sending SIGPWR to init when some UPS event arrives, but it's just an
example, and in that setting spawning some script would be a better approach
anyway. The same applies to pretty much anything else in userspace that might
be monitoring power supply. It should not be signalling init, it should
have some sort of a configuration event handler.

Unless it's matter of principle, hard-coding SIGPWR as a shutdown signal
sounds like a decent idea to me, at least on Linux. LXD and similar
containers might be the only class of applications for which signalling
init like that actually makes sense. The distinction between SIGINT for
reboot and SIGPWR for shutdown does not sound awful either.