![](https://seccdn.libravatar.org/avatar/3ec791b178b445bf91ca15a5ffb361b9.jpg?s=120&d=mm&r=g)
Hello, with https://github.com/openSUSE/aaa_base/pull/138 ptrace got disabled by default on Tumbleweed by setting kernel.yama.ptrace_scope = 1 This means that you can't ptrace your own processes in the default configuration (e.g. use strace -p to attach to a running process). This was done because the vast majority of users don't need the funcionality and malware can abuse it to e.g. steal credentials. If you need this functionality (and since you read the list the chances are high) you can set kernel.yama.ptrace_scope back to the default value of 0 and get the old behavior back. Johannes -- GPG Key EE16 6BCE AD56 E034 BFB3 3ADD 7BF7 29D5 E7C8 1FA0 Subkey fingerprint: 250F 43F5 F7CE 6F1E 9C59 4F95 BC27 DD9D 2CC4 FD66 SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nürnberg, Germany Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg)
![](https://seccdn.libravatar.org/avatar/77cb4da5f72bc176182dcc33f03a18f3.jpg?s=120&d=mm&r=g)
On 2024-05-03 14:24, Johannes Segitz wrote:
Hello,
with https://github.com/openSUSE/aaa_base/pull/138 ptrace got disabled by default on Tumbleweed by setting kernel.yama.ptrace_scope = 1 This means that you can't ptrace your own processes in the default configuration (e.g. use strace -p to attach to a running process).
This was done because the vast majority of users don't need the funcionality and malware can abuse it to e.g. steal credentials.
If you need this functionality (and since you read the list the chances are high) you can set kernel.yama.ptrace_scope back to the default value of 0 and get the old behavior back.
Does this need recompiling? Is it a boot option only, or can it be done after the system is booted? -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
![](https://seccdn.libravatar.org/avatar/3ec791b178b445bf91ca15a5ffb361b9.jpg?s=120&d=mm&r=g)
On Fri, May 03, 2024 at 02:44:56PM +0200, Carlos E. R. wrote:
Does this need recompiling?
no, it's a sysctl option
Is it a boot option only, or can it be done after the system is booted?
Just run sysctl kernel.yama.ptrace_scope=0 and you're set for the current boot. Or set it permenantly in /etc/sysctl.d/ Johannes -- GPG Key EE16 6BCE AD56 E034 BFB3 3ADD 7BF7 29D5 E7C8 1FA0 Subkey fingerprint: 250F 43F5 F7CE 6F1E 9C59 4F95 BC27 DD9D 2CC4 FD66 SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nürnberg, Germany Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg)
![](https://seccdn.libravatar.org/avatar/77cb4da5f72bc176182dcc33f03a18f3.jpg?s=120&d=mm&r=g)
On 2024-05-03 16:26, Johannes Segitz wrote:
On Fri, May 03, 2024 at 02:44:56PM +0200, Carlos E. R. wrote:
Does this need recompiling?
no, it's a sysctl option
Is it a boot option only, or can it be done after the system is booted?
Just run sysctl kernel.yama.ptrace_scope=0 and you're set for the current boot. Or set it permenantly in /etc/sysctl.d/
Perfect, thanks :-) -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
![](https://seccdn.libravatar.org/avatar/7c8ecf833fc556303e962892f5c0afc6.jpg?s=120&d=mm&r=g)
Am Freitag, dem 03.05.2024 um 14:24 +0200 schrieb Johannes Segitz:
Hello,
with https://github.com/openSUSE/aaa_base/pull/138 ptrace got disabled by default on Tumbleweed by setting kernel.yama.ptrace_scope = 1 This means that you can't ptrace your own processes in the default configuration (e.g. use strace -p to attach to a running process).
This was done because the vast majority of users don't need the funcionality and malware can abuse it to e.g. steal credentials.
If you need this functionality (and since you read the list the chances are high) you can set kernel.yama.ptrace_scope back to the default value of 0 and get the old behavior back.
Huh, I've ran into issues with kernel.yama.ptrace_scope=1 faster than I've expected. In my particular case it was the JVM needing to spawn gdb on itself in case of an error, as gdb cannot spawn the JVM the normal way around. Generally, as change means that gdb -p <pid> doesn't work at all anymore I suspect a lot more than just readers of this list will be affected by this change. Shouldn't they be notified about this too?
Johannes
With kind regards,
Florian "sp1rit"
--
$\int_\text{now}^{+\infty}\text{Keep trying}$
Matrix: @sp1rit:tchncs.de
participants (3)
-
Carlos E. R.
-
Florian "sp1rit"
-
Johannes Segitz