Dear Maintainer, #704750 in 2013 requested Yama – a kernel feature that restricts PTRACE_ATTACH to parent processes and root (by default, it can be configured). #712740 a few months later requested it to be disabled by default because it prevents some debugging operations. This is done via the yama-disable-by-default.patch. With this bug I want to request dropping this patch. Yama is a security feature: without it any process in a user session can to attach to (almost) any other one run by the same user. Yes, it makes debugging a bit harder, but a) most users don't debug stuff b) child processes are unaffected (so gdb myprog still works) c) it can be easily disabled with a sysctl d) you could run your debugger as root instead (or with CAP_SYS_PTRACE) As an aside: Ubuntu had this enabled for years now (10.10, I think). (Though they also patch e.g. gdb to produce better error messages, see ptrace- error-verbosity.patch.)
close 1025071 thanks Closing as we did not re-consider the decision of dropping the patch for a few releases. If someone strongly disagrees, feel free to reopen the bug providing fresh information why we should still aim to drop the patch. Thanks for your understanding, Regards, Salvatore
Moin, Could you please elaborate on the decision to close this without reconsidering? Essentially, the option to use a security feature is taken away from users (i.e., no option to enable it without rebuilding the kernel); Not taking the option away from users would mean that those who would want to disable it would have to use an available sysctl. To me, the latter sounds very much like an ideal scenario from a usability/security trade-off? With best regards, Tobias
Moin Tobias, Thanks for acting on the bug. Let me try to be more verbose. There are the mentioned issues in the bug which explain why in Debian the decision was to disable yama by default (instead of having enabled it by default), which are related to debugging. It does not mean that users cannot take advantage of the Yama protection, but the sysctl know need to enable it. So it is just hte other way around. What I mean with not having reconsidered is that the potential change has not made it to neither bookworm, nor trixie (to late now) and we have not seen other real interest to have it reversed. In the sense to finally clean up our longstanding bugs down I have decided to close the bug, still with a clear note that if people feel strong about the decision to reopen the bug with an expalnation on why a particular feature is still desired (this time maybe for Debian forky). Hope this englights on the purpose of the bug closure. Regards, Salvatore
Moin Tobias, Thanks for acting on the bug. Let me try to be more verbose. There are the mentioned issues in the bug which explain why in Debian the decision was to disable yama by default (instead of having enabled it by default), which are related to debugging. It does not mean that users cannot take advantage of the Yama protection, but the sysctl know need to enable it. So it is just hte other way around. What I mean with not having reconsidered is that the potential change has not made it to neither bookworm, nor trixie (to late now) and we have not seen other real interest to have it reversed. In the sense to finally clean up our longstanding bugs down I have decided to close the bug, still with a clear note that if people feel strong about the decision to reopen the bug with an expalnation on why a particular feature is still desired (this time maybe for Debian forky). Hope this englights on the purpose of the bug closure. Regards, Salvatore
Hi Salvatore, I'm not entirely sure how to reply to this. I feel strongly about this issue; that's why I opened the bug in the first place. Salvatore Bonaccorso wrote: Well, yes, thanks for correcting Tobias, but I don't think this is a good default. Almost no users will enable this setting, because they won't know that it exists. I know about the line in dmesg but I really doubt that people are going to read their dmesg line by line and search for possible options. Also, most users probably won't debug applications. Sorry, but this is a circular argument. "We're not doing it because we haven't done it yet." Cheers, Niklas
Control: reopen -1 Control: found -1 6.1.135-1 Control: found -1 6.12.25-1 Control: found -1 6.13.5-1~exp1 Hi Niklas, What you did was exactly was i was looking for (more below) Those are good arguments, and we need to re-evaluate if our stance that default off for the benefits of the debugging possibilties are still on the weight balance were we want. So I'm opening the bug with this fresh information and updated metadata. let me paraphrase it differently: There was no action on the bug and not much inerest in acting people to do "something" about it. The kernel team had only few months back more than 1000 open bugs, making the situation very unhealthy. With this action of closing longstanding but undhandled bugs (with a hopeful good explanation in my mail template, was it? what was missing for you as user/reporter?) we brought the bug list down to now less than 200, with the option that people affected by bugs (or having deposited a wishlist bug or feature request) still caring obut the problem can approach us. it is very important to me to make the statement that we do not want to just rationalize away the bugs, but get confronted with what is current. You explicitly showed interest that the situation is still handled, after a couple of years of inactivity, and we take this seriously. So this gives us the chance now to either reconsider the decision of disabling yama by default or -- close the bug with a sensible rationale why we want to keep this (but then it is not just a bug without any reply from our team, which is sad for any reporter). Regards, Salvatore
Hi Niklas, Spending another little bit on time on it and preparing the update in https://salsa.debian.org/kernel-team/linux/-/merge_requests/1507 I still think there might be compelling reasons that we don't to nothing, but in that case it would be documented at least properly in the bugreport. #712740 stated the reasons why it was not enabled by default, and up to today at least gdb upstream still does not have the patch which Ubuntu applies (TTBOMK!). Ben correctly pointed out that it should not be done independly in Distros to add better warnings, but if that is considered a worthwile default setting, then upstream tools should have the patches applied. Apparently though that after years still did not happen, it might not have enough drift to do so. Anyway I have put that now into discussion for the team so we can properly decide on an outcome. Regards, Salvatore
Hi Salvatore, I've been wondering whether the recent ptrace bug (https://seclists.org/oss-sec/2026/q2/529?) would be exploitable with the default kernel.yama.ptrace_scope=1 – and yes, it still is. Setting it to 2 seems to prevent it, though. (After typing this email, I saw that you also had this idea, but I figured it might be helpful to have this information in this thread.) Cheers, Niklas