|
Top-level
 It's in fact so drastic that it even kills PID 1 if it is currently in the process in writing its pretty status update messages to the console, instantly killing your system. (Because of this, PID 1 will only briefly open the console when doing an update, but it's still racy) Moreover the kernel SAK concept is relatively easy to circumvent: if a user has access to the console, and their processes that have the console open are killed then nothing stops them to immediately reopen the console… 7 comments
This should be a much friendlier SAK implementation: the original session is not terminated, but just switched away, taking away control of the keyboard, mouse and screen, without chance for the unprivileged code to interfere. Note that before this actually becomes useful the display managers of the various desktop environments need to be updated to watch for the SAK signal. But the groundwork is laid now. And that's it for today.  @pid_eins Can I define a custom key combination? How are alternate keyboard layouts handled (e.g. Mac)?  @mariusor well, if dbus is hosed, systemd is pretty much hosed, too. SAK is probably the least of you problems then.  |
Gregory's Server
… and continue with their nefarious deeds.
With systemd v257 we added support for an alternative SAK implementation that should not suffer by these limitations: logind will now watch input devices for the Ctrl+Alt+Shift+Esc key combination, continously, regardless which session is in the foreground. Once it sees the combination being hit, it fires off a D-Bus signal.
The idea is then that the display manager sees this signal, and switches back to the the login screen in a reliable manner.