Description of problem: REISUB do not work So I could not get out of a problem -> more risk of loosing work and harder to debug Of the famous REISUB, only the S (Emergency Sync) is accepted Version: systemd-258.3-1.mga10 Kernel kernel-desktop-6.18.9-1.mga10-1-1.mga10.x86_64 How reproducible, Steps to Reproduce: Fresh install mga10beta1round1 plus updates during install Enabled in kernel: [root@hp1 ~]# zcat /proc/config.gz | grep MAGIC_SYSRQ CONFIG_MAGIC_SYSRQ=y CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE=0x1 CONFIG_MAGIC_SYSRQ_SERIAL=y CONFIG_MAGIC_SYSRQ_SERIAL_SEQUENCE="" Disabled by setting: [root@hp1 ~]# sysctl kernel.sysrq kernel.sysrq = 16 Should be 1; can be set manually (temporarily) by # sysctl -w kernel.sysrq=1 And then REISUB works
This is constantly getting reset. Somebody, probably upstream, got the idea that there was a "danger" that these keys could be hit unintentionally. This goes back years now.
CC: (none) => ftg
The file setting this is /usr/lib/sysctl.d/50-default.conf which belongs to systemd. We have to change there if we want to change the default for everyone.
CC: (none) => ghibomgx
Also in Mageia 9, I see [morgan@svarten ~]$ cat /usr/lib/sysctl.d/50-default.conf | grep kernel.sysrq # Use kernel.sysrq = 1 to allow all keys. kernel.sysrq = 16 So this should to be reverted in Mageia 9 too, for new installs with updates during install. Apparently the original settings from install is remembered: (I dont know how) [morgan@svarten ~]$ sysctl kernel.sysrq kernel.sysrq = 1 [morgan@svarten ~]$ rpm -qa --last | grep systemd systemd-253.33-1.mga9.x86_64 ons 4 jun 2025 17:30:08 lib64systemd0-253.33-1.mga9.x86_64 ons 4 jun 2025 17:30:07 python3-systemd-235-1.mga9.x86_64 lör 10 feb 2024 21:02:38 rpm-plugin-systemd-inhibit-4.18.2-1.mga9.x86_64 mån 4 dec 2023 17:24:43
Flags: (none) => affects_mga9+
(In reply to Giuseppe Ghibò from comment #2) > The file setting this is /usr/lib/sysctl.d/50-default.conf which belongs to > systemd. We have to change there if we want to change the default for > everyone. In order to not make a change we have now to set it back to as it was at Mageia 9 release. *If* we should keep the current change it need a wider voting, maybe council.
It seems that in mga9 there is an extra /etc/sysctl.d/51-alt-sysrq.conf, that it's not present in mga10 anymore.
(In reply to Frank Griffin from comment #1) > This is constantly getting reset. Somebody, probably upstream, got the idea > that there was a "danger" that these keys could be hit unintentionally. > > This goes back years now. I really not see how somebody could use by accident these combinations :S O_o For me is a bad joke see Linux users mocking windows for Ctrl+Alt+Del when this is harder to do and remember ;)
(In reply to Giuseppe Ghibò from comment #5) > It seems that in mga9 there is an extra /etc/sysctl.d/51-alt-sysrq.conf, > that it's not present in mga10 anymore. https://svnweb.mageia.org/packages/cauldron/systemd/current/SPECS/systemd.spec?r1=2061666&r2=2061665&pathrev=2061666
CC: (none) => davidwhodgins
CC: (none) => jani.valimaa
If is for security https://www.debian.org/doc/manuals/securing-debian-manual/restrict-sysrq.html , we need to notify to our users of this change and how enable if they want
Flags: (none) => in_errata10?Keywords: (none) => FOR_ERRATA9
Works in Mageia 9 by the extra file see Comment 7 Mageia 10 should have the same file, then no Errata entry needed. If we keep it as it is currently in Cauldron/10beta1 then it is a change from Mageia 9 and i think should be voted on first. IMO it would be ridiculous to restrict it as now. If users have access to keyboard they on normal computers also reach power or reset button and from grub can get to console as root easily anyhow...
Keywords: FOR_ERRATA9 => (none)
Note that the extra file containing the sysrq entry on mga9 is outside any %config(...) file, so it's preserved when upgrading from Mageia 9 to Mageia 10, but not on a clean Mageia 10 installation. Looking around, we see: - RHEL: sysrq -> 16 (allowing only remounting as read-only) - Fedora: sysrq -> 16 (same) - Ubuntu: sysrq -> 176 (allowing remounting RO, reboot and sigkill/term) In my opinion, there's a tendency to hide internals with removing the "killer switches": Wayland no longer allows killing the session with Ctrl+Alt+Backspace (because by design "it's a protocol"), Plymouth only cycles through its animation, hiding startup services logs, and so on. Now RSEIUB... On average, we're slowly losing many of the commodities we've become accustomed to since the early days of Linux... :-)
Created attachment 15413 [details] Message confirming the decision to default to the insecure settings was intentional In 2014, the last time the change was made to disable sysrq by default, the council decided against it, after getting complaints during iso testing. ml.mageia.org archives don't go back that var, so I'm attaching the msg from tmb confirming that it was intentional. Up to you and the current council whether or not to revisit the issue.
(In reply to Dave Hodgins from comment #11) > Created attachment 15413 [details] > Message confirming the decision to default to the insecure settings was > intentional > > In 2014, the last time the change was made to disable sysrq by default, the > council decided against it, after getting complaints during iso testing. > > ml.mageia.org archives don't go back that var, so I'm attaching the msg from > tmb confirming that it was intentional. > > Up to you and the current council whether or not to revisit the issue. Here is the original Bugzilla report where this was discussed: https://bugs.mageia.org/show_bug.cgi?id=10473
CC: (none) => rihoward1
It's a trade off. If RSEISUB is allowed, then if you leave a system unattended with just a screen locker protecting it, and other people have physical access, then there is the potential they will succeed in getting access. If it's disallowed, you may lose data since you can not force a sync before using the power button to do a cold boot. Doing a cold boot without syncing first may (probably will) cause file system corruption, which may or may not be recoverable. msec should disable it for people that need very high security, but for most people the threat of data loss is a much bigger concern than an attacker with physical accesss.
(In reply to Dave Hodgins from comment #11) > Created attachment 15413 [details] > Message confirming the decision to default to the insecure settings was > intentional > > In 2014, the last time the change was made to disable sysrq by default, the > council decided against it, after getting complaints during iso testing. > > ml.mageia.org archives don't go back that var, so I'm attaching the msg from > tmb confirming that it was intentional. > > Up to you and the current council whether or not to revisit the issue. A curiosity: At the bottom of the message we had the size of the Mga4 ISOs at 28 Jan 2014: # du -sh */*.iso 657M Mageia-4-LiveCD-GNOME-en-i586-CD.iso 650M Mageia-4-LiveCD-KDE4-en-i586-CD.iso 1.4G Mageia-4-LiveDVD-GNOME-i586-DVD.iso 1.4G Mageia-4-LiveDVD-GNOME-x86_64-DVD.iso 1.5G Mageia-4-LiveDVD-KDE4-i586-DVD.iso 1.5G Mageia-4-LiveDVD-KDE4-x86_64-DVD.iso
When there are multiple builds of the iso images before it passes qa, the qa team includes info to make it clear which build they are using.
(In reply to Dave Hodgins from comment #13) > msec should disable it for people that need very high security Yes it would be good if security level in msec could control the behaviour. Then again, a good admin can change kernel.sysrq from wahtever we set as default. Our default should be to allow user to perform REISUB. > most people the threat of data loss is a much bigger concern than an > attacker with physical accesss. Absolutely. And for recovering and debugging hangs... At least it is good hat currently mga10 allow Emergency Sync, so journal get saved, and files - although not closed correctly then - the E and I in REISUB helps a bit there, and U & B is for rebooting - better than power or reset button and no security risk IIUC. And remember usually the computer can be restarted by power button, and our grub menu have an option to boot to prompt as root... - Blocking Magic Sysrq seem pretty futile security wise if not combined with securing the boot process.
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=10473Priority: Normal => release_blocker
Flags: affects_mga9+ => affects_mga9-
CC: (none) => cooker
(In reply to Giuseppe Ghibò from comment #10) > Note that the extra file containing the sysrq entry on mga9 is outside any > %config(...) file, so it's preserved when upgrading from Mageia 9 to Mageia > 10, but not on a clean Mageia 10 installation. Which is good. > In my opinion, there's a tendency to hide internals with removing the > "killer switches": Wayland no longer allows killing the session > with Ctrl+Alt+Backspace (because by design "it's a protocol"), Plymouth only > cycles through its animation, hiding startup services logs, and so on. Now > RSEIUB... The tendency is to treat the admin as a stupid guy instead of empowering him. That's a philosophical choice for the distribution: Do we want to give power to our users or not ? My vote is clearly YES, with explanations. > On average, we're slowly losing many of the commodities we've become > accustomed to since the early days of Linux... :-) And I'm so sad it's becoming like that :-( And as said elsewhere, when you have physical access to a machine, pretending that removing Alt-SysRq feature increases security is also a stupidity.
CC: (none) => bruno
So are we fixing this for mga10 release? If no decision - please revert to having it enabled like on mga9.
(In reply to Morgan Leijström from comment #18) > So are we fixing this for mga10 release? > > If no decision - please revert to having it enabled like on mga9. +1
CC: (none) => marja11
If we decide to not revert: entry in release notes If no decision and no revert: entry in errata In both cases describe for user how to enable.
Flags: (none) => in_release_notes10?
I think the only useful places to disable SysRq are for kiosks (specifically those with keyboards) and classrooms, where you want to prevent students from terminating the screensaver or causing unwanted reboots (maybe each other). However, in most other cases, it's still useful to have SysRq enabled. Instead of re-enabling it in systemd, we could move the SysRq enabling configuration file to one of the Mageia customizing packages, using a %config(noreplace) directive for better tracking.
(In reply to Giuseppe Ghibò from comment #21) > I think the only useful places to disable SysRq are for kiosks (specifically > those with keyboards) and classrooms, where you want to prevent students > from terminating the screensaver or causing unwanted reboots (maybe each > other). > > However, in most other cases, it's still useful to have SysRq enabled. > Instead of re-enabling it in systemd, we could move the SysRq enabling > configuration file to one of the Mageia customizing packages, using a > %config(noreplace) directive for better tracking. I fully agree with this. The SysRq sequences are often the safest way to cleanly force a system reset without losing data at the same time. Sometimes I have to use it when shutting down, because some process takes way to long and my UPS battery is running low. It has always been available in Linux since the version 2.1 series. So why disable it now?
(In reply to Giuseppe Ghibò from comment #21) > Instead of re-enabling it in systemd, we could move the SysRq enabling > configuration file to one of the Mageia customizing packages, using a > %config(noreplace) directive for better tracking. maybe initscripts or a dedicated task-sysrq ?
I propose creating a new package, "mageia-sysrq-config-1.0", to enable the Magic SysRq key. This package would contain only the "/etc/sysctl.d/51-alt-sysrq.conf" file, setting "kernel.sysrq = 1". This would split the configuration from systemd. We just need to add it to the rpmsrate. Users can uninstall it if they don't need it. Unless anyone objects, I will add it to the distribution.
I think this, Comment 24, is a good solution.