Re: Unable to disable SysRq
On Tue, Nov 17, 2020 at 04:08:19PM +0100, Vitaly Zaitsev via devel wrote: > That's why all user-space "OOM killers" must have the following > lines in their .service files: > > DynamicUser=true > AmbientCapabilities=CAP_KILL CAP_IPC_LOCK > ProtectSystem=strict > ProtectHome=true > > I think FESCo should create a special policy for such preinstalled > by default daemons. Running them as root is too dangerous. See https://pagure.io/fesco/issue/1663 and the linked FPC ticket. I'm not sure if that draft ever made it officially into the guidelines? -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Unable to disable SysRq
On 17.11.2020 13:26, Robert Marcano via devel wrote: User d9k on IRC found the culprit. It is low-memory-monitor. The latest commit [1] for it tries to not mess with the value with 1 is set, but it should not mess with it ever. That's why all user-space "OOM killers" must have the following lines in their .service files: DynamicUser=true AmbientCapabilities=CAP_KILL CAP_IPC_LOCK ProtectSystem=strict ProtectHome=true I think FESCo should create a special policy for such preinstalled by default daemons. Running them as root is too dangerous. Earlier, in cooperation with the upstream, we fixed the earlyoom daemon. It has no root access to the system and can only kill processes using ambient capabilities. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Unable to disable SysRq
On 11/17/20 8:26 AM, Robert Marcano wrote: User d9k on IRC found the culprit. It is low-memory-monitor. The latest commit [1] for it tries to not mess with the value with 1 is set, but it should not mess with it ever. The same documentation on that commit references [2] where it says: Note that the value of ``/proc/sys/kernel/sysrq`` influences only the invocation via a keyboard. Invocation of any operation via ``/proc/sysrq-trigger`` is always allowed (by a user with admin privileges). [1] https://gitlab.freedesktop.org/hadess/low-memory-monitor/-/commit/11560bc102941c95890c0852f2d9b166853b4f6a [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/admin-guide/sysrq.rst Will submit a bug (if d9k already hasn't done that). Reported upstream and a tracking bug on bugzilla https://gitlab.freedesktop.org/hadess/low-memory-monitor/-/issues/11 https://bugzilla.redhat.com/show_bug.cgi?id=1898524 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Unable to disable SysRq
On Tue, Nov 17, 2020 at 01:10:02PM +0100, Kevin Kofler via devel wrote: > Robert Marcano via devel wrote: > > Two times in a week I have killed all processes trying to use Alt+i. Ts > > is to easy to press the Alt and the PrtScr at the same, starting that > > way the SysRq i command. > > > > So before staring to write a kernel patch to add an option where the > > SysRq is only triggered by the Left Alt key. I decided to initially > > disable sysrq entirely. > [followed by technical details of why that failed] > > This is funny because SysRq is supposed to be disabled by default in Fedora > to begin with, for security reasons. According to https://fedoraproject.org/wiki/QA/Sysrq 16 - enable sync command 64 - enable signalling of processes (term, kill, oom-kill) 80 = 16+64 and enables both of the above. Sync seems safe to always leave enabled. Killing processes probably not. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Unable to disable SysRq
On 11/16/20 8:25 PM, Robert Marcano wrote: I am using a ThinkPad with one of these keyboards where the PrtScr key is between the right Alt and Ctrl, an awful position. Two times in a week I have killed all processes trying to use Alt+i. Ts is to easy to press the Alt and the PrtScr at the same, starting that way the SysRq i command. So before staring to write a kernel patch to add an option where the SysRq is only triggered by the Left Alt key. I decided to initially disable sysrq entirely. My Fedora 33 kernel.sysrq value is 80, the default at /usr/lib/sysctl.d/50-default.conf say that it should be 16. Created /etc/sysctl.d/99-local.conf with kernel.sysrq=0, but after boot the value is 64, only after a single user mode boot the value stays at 0. Some other thing is enabling the 64 bit, Asked on IRC and another user has 80 on Fedora Workstation and 16 on Server. I tried disabling all non default services on my installation but to no effect, the 64 bit is always enabled. Fedora 33 Live CD shows 16 as the default is configured. How can I log what process is changing values on the sysctl variables? or anyone has aon idea of what is happening here? User d9k on IRC found the culprit. It is low-memory-monitor. The latest commit [1] for it tries to not mess with the value with 1 is set, but it should not mess with it ever. The same documentation on that commit references [2] where it says: Note that the value of ``/proc/sys/kernel/sysrq`` influences only the invocation via a keyboard. Invocation of any operation via ``/proc/sysrq-trigger`` is always allowed (by a user with admin privileges). [1] https://gitlab.freedesktop.org/hadess/low-memory-monitor/-/commit/11560bc102941c95890c0852f2d9b166853b4f6a [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/admin-guide/sysrq.rst Will submit a bug (if d9k already hasn't done that). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Unable to disable SysRq
Robert Marcano via devel wrote: > Two times in a week I have killed all processes trying to use Alt+i. Ts > is to easy to press the Alt and the PrtScr at the same, starting that > way the SysRq i command. > > So before staring to write a kernel patch to add an option where the > SysRq is only triggered by the Left Alt key. I decided to initially > disable sysrq entirely. [followed by technical details of why that failed] This is funny because SysRq is supposed to be disabled by default in Fedora to begin with, for security reasons. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Unable to disable SysRq
On Mon, Nov 16, 2020 at 11:35:41PM -0800, Samuel Sieb wrote: > On 11/16/20 4:25 PM, Robert Marcano via devel wrote: > >My Fedora 33 kernel.sysrq value is 80, the default at > >/usr/lib/sysctl.d/50-default.conf say that it should be 16. > > > >Created /etc/sysctl.d/99-local.conf with kernel.sysrq=0, but after > >boot the value is 64, only after a single user mode boot the value > >stays at 0. That should work. I just tested such setup locally, and after running 'sudo systemctl restart systemd-sysctl', 'sysctl kernel.sysrq' reports 0. So it really seems like something else is setting it. On another machine, I have '80', even though the config says '16'. > >Some other thing is enabling the 64 bit, Asked on IRC and another > >user has 80 on Fedora Workstation and 16 on Server. > > > >How can I log what process is changing values on the sysctl > >variables? or anyone has aon idea of what is happening here? > > This is a very curious issue. I checked on various computers I have > around. All the F32 systems have 16. My one laptop that was > installed with the Gnome desktop, but not directly Workstation and > has now been upgraded to F33 is still 16. However, two other > computers that were installed with F32 Workstation switched to 80 > when upgraded to F33. I have not been able to figure out what is > causing that, but it does seem to be related to the Workstation > config somehow. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Unable to disable SysRq
On 11/16/20 4:25 PM, Robert Marcano via devel wrote: My Fedora 33 kernel.sysrq value is 80, the default at /usr/lib/sysctl.d/50-default.conf say that it should be 16. Created /etc/sysctl.d/99-local.conf with kernel.sysrq=0, but after boot the value is 64, only after a single user mode boot the value stays at 0. Some other thing is enabling the 64 bit, Asked on IRC and another user has 80 on Fedora Workstation and 16 on Server. How can I log what process is changing values on the sysctl variables? or anyone has aon idea of what is happening here? This is a very curious issue. I checked on various computers I have around. All the F32 systems have 16. My one laptop that was installed with the Gnome desktop, but not directly Workstation and has now been upgraded to F33 is still 16. However, two other computers that were installed with F32 Workstation switched to 80 when upgraded to F33. I have not been able to figure out what is causing that, but it does seem to be related to the Workstation config somehow. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Unable to disable SysRq
I am using a ThinkPad with one of these keyboards where the PrtScr key is between the right Alt and Ctrl, an awful position. Two times in a week I have killed all processes trying to use Alt+i. Ts is to easy to press the Alt and the PrtScr at the same, starting that way the SysRq i command. So before staring to write a kernel patch to add an option where the SysRq is only triggered by the Left Alt key. I decided to initially disable sysrq entirely. My Fedora 33 kernel.sysrq value is 80, the default at /usr/lib/sysctl.d/50-default.conf say that it should be 16. Created /etc/sysctl.d/99-local.conf with kernel.sysrq=0, but after boot the value is 64, only after a single user mode boot the value stays at 0. Some other thing is enabling the 64 bit, Asked on IRC and another user has 80 on Fedora Workstation and 16 on Server. I tried disabling all non default services on my installation but to no effect, the 64 bit is always enabled. Fedora 33 Live CD shows 16 as the default is configured. How can I log what process is changing values on the sysctl variables? or anyone has aon idea of what is happening here? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
