re-enable full normal functionality system-wide

I don't think calling ptrace_scope = 0 "normal" is accurate. The kernel upstream is (and always was?) ptrace_scope = 1.

I also don't particularly like that on a multi-user system, one user installing gdb causes an override that affects all users on the system, not just the user who installed the tool.

Still, this is (slightly) better than the status quo, so I'm not against the change: ±0

I'm against the idea of having a core security feature of the system be disabled by installing a package. This leaves us with a trivial-to-exploit security hole where any malicious third-party RPM could Requires: gdb-minimal and automatically reduce the security of the system.

I'm aware that the end-result here would be that the outcome here is that we are essentially in the same position we started in, but with one critical detail: we expect to be more secure, but we may actually not be (and there's no obvious notification to the user when the security is reduced).

So, I'm a weak -1 here, but I'm open to ideas on how to mitigate these concerns.

This leaves us with a trivial-to-exploit security hole where any malicious third-party RPM could

Surely a malicious RPM could just drop in a file to change the sysctl directly regardless, it doesn't need to use this dep. A user has to trust any yum repo they choose to enable.

How does this work if gdb is installed in a toolbox?

It'll do nothing.

During discussion at FESCo, we noted that the ABRT package dependency chain would result in almost all existing deployments pulling in this package, so I'm not convinced that there's any meaningful change being made here. We're planning to drop ABRT in F45, but that doesn't help folks who are upgrading.

Additional questions from the discussion:

• how many fedora systems will get the secure profile effectively?
  • does gdb-headless pull it in
  • does abrt pull it in
• how does this interact with SELinux?
  • if gdb* is removed, does the more permissive config get removed as well?

We're planning to drop ABRT in F45, but that doesn't help folks who are upgrading.

We don't know this either, so we should assume ABRT is going to stick around.

This was discussed during today's meeting:

INFO: Still waiting for information from the Change owners, topic will be discussed again next week.

see meeting log, starting at 19:04: https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2026-03-03/fesco.2026-03-03-18.03.log.html

It seems I have not been subscribed to this topic, so I missed that posts have been made (I expected to get mail:). Sorry.

how does this interact with SELinux?

Not at all. SELinux would have its own boolean for restricting ptrace, but that is not an option as it is closer to ptrace_scope=2 globally and thus even more invasive/restrictive than my earlier proposals with ptrace_scope=1 globally.

By default, we (Fedora,CentOS,Alma,Rocky) deploy unconfined_u SELinux profiles for all user accounts, and therefore SELinux does not add protection about ptrace within user accounts. It’s widely inactive in that respect.

The kernel default on itself (ptrace_scope=1) does not need adjustments in terms of SELinux policies or so. The two do not interact but act separately as two layers: if something is permitted by both, it works out fine. If something is restricted by any one of the two or both, it is blocked. So for this discussion, it is only relevant if and what ptrace_scope=1 is blocking or not :) No SELinux impact/implication.

I cannot give reliable detailed answers about the other questions but would trigger first @fche and @mjw . I assume they also have not been triggered yet :) However, ...

if gdb* is removed, does the more permissive config get removed as well?

If the dependency would be of gdb, removing gdb would also remove the package again. But once gdb is installed, ptrace_scope would be set to 0.

Keep in mind that at the moment this package is installed globally, on every Fedora by default. The discussion above reads partially a little like we would decrease the security.

how many fedora systems will get the secure profile effectively?

This will be impacted by the maintainers of gdb, etc. A default installation should be free of the package and thus have ptrace_scope=1 kernel default.

one user installing gdb causes an override that affects all users on the system, not just the user who installed the tool.

I'm against the idea of having a core security feature of the system be disabled by installing a package

I don't see how the original FESCo decision about my earlier proposal could lead to anything else. Not sure what expectations FESCo had back then? The possibilities are limited. We cannot make gdb and such work by default for all developers and still have ptrace_scope=1 protection. Making this possible would be more an upstream kernel contribution, if possible at all :)

Please be aware that something about the fesco / change communication machinery is REALLY BROKEN. I as a change owner am receiving no notification that the topic's going to be discussed at a particular fesco meeting, no subscription to this forum, so I have no idea that any of this is going on until someone kindly manually cc:'d me out of pure courtesy. Please fix this.

Change owners should get CC'd / subscribed on tickets, but this looks broken in the conversion to AI assisted Change wrangling - see also the non-functional @-mentions in the ticket body.

(Though, in general, if a ticket is tagged with "meeting", it will be discussed during the next meeting.)

(Though, in general, if a ticket is tagged with "meeting", it will be discussed during the next meeting.)

We did not get notification of this ticket even existing.

Yes, hence my comment about "this looks broken in the conversion to AI assisted Change wrangling". Though it was announced in the discussion thread: https://discussion.fedoraproject.org/t/180476/9

We try to fix instances where broken tickets are created, but that's a sisyphean task, and we miss things. Ideally we wouldn't get broken tickets filed, but that's apparently the future our AI overlords have in store for us.

re-enable full normal functionality system-wide
I don't think calling ptrace_scope = 0 "normal" is accurate.

Call it "status quo" if you like.

The kernel upstream is (and always was?) ptrace_scope = 1.

No, not always.

I also don't particularly like that on a multi-user system, one user installing gdb causes an override that affects all users on the system, not just the user who installed the tool.

The hard-line "restrict ptrace until user somehow manually turns it on" change was rejected a monthish ago. This specific compromise proposal was requested by FESCO at that time. Yes, this is only a compromise, and helps add a smidgen of security to a subset of installations, while maintaining normal status quo function on other installations.

Though it was announced in the discussion thread: https://discussion.fedoraproject.org/t/180476/9

I'm sorry, but that discussion thread is also failed to generate notifications. Nor did a notification come in from the wiki Change page when the FESCO issue link was added there.

In an attempt to move this discussion in a constructive direction, and in the light of the original FESCo decision and conditions, and in the light of the technical possibilities: does it make sense to shift the discussion to the question of which packages should be dependent in which way on the yama-ptrace-enable (future name of elfutils-default-yama-scope)?

The conditions we have can only result in the package to remain in some way, so FESCo might either accept this as being a little better than the current state, reject it, or contribute to the solution more actively.

Questioning a compromise that is more or less what we had been asked for without providing alternatives or clearly formulated expectations/requirements (that are aligned among FESCo members) does not add value, it only facilitates that we start the same circle with the same questions again.

We will (with very high likelihood) discuss this topic again next week (March 10, 2026, at 18:00 GMT, in #fedora-meeting@fedorproject.org).

It would be great if we could get definitive answers to the questions that made us skip the topic yesterday ( https://pagure.io/fesco/issue/3569#comment-1006740 ) then, or here.

As for ongoing issues with the Change wrangling process, see also tickets #3515 and #3524 - this is mostly out of our control, please complain to Red Hat instead.

Hi all, I am reading through this and seeing now some issues with the way fesco tickets are being created. I am happy to help fix this. I stepped into the Change Wrangler role while Aoife is on leave, with this being my first foray into the Fedora development, so despite having clear instructions from here, there are nuances that I am missing at times. While I am using AI to help me, I am still a human behind the tools and if you provide me with direct and actionable feedback, I will address the issues you are facing with how changes are being processed.

I know we have https://pagure.io/fesco/issue/3515 and https://pagure.io/fesco/issue/3524, both of these seem higher-level and more strategic. Should we create a new ticket for the more granular issues with the processing?

@fche I answered already the question about SELinux, but I would leave the definitive answer to the other questions [1] to you, it's mostly yes/no booleans anyway:

Additional questions from the discussion:

how many fedora systems will get the secure profile effectively?
- does gdb-headless pull it in
- does abrt pull it in
if gdb* is removed, does the more permissive config get removed as well?

[1] https://pagure.io/fesco/issue/3569#comment-1006740

We will (with very high likelihood) discuss this topic again next week (March 10, 2026, at 18:00 GMT, in #fedora-meeting@fedorproject.org).

OK!

It would be great if we could get definitive answers to the questions that made us skip the topic yesterday ( https://pagure.io/fesco/issue/3569#comment-1006740 ) then, or here.

OK.

As for ongoing issues with the Change wrangling process, see also tickets #3515 and #3524 - this is mostly out of our control, please complain to Red Hat instead.

Until automation is fixed, could we perhaps have whoever is filing fesco tickets, please ensure manually that the change proposers are cc:'d on them?

• how many fedora systems will get the secure profile effectively?

I know of no way of knowing this, lacking fedora rpm installation telemetry.

• does gdb-headless pull it in

It could. It may be that the gdb-headless package is entirely used by packages that use it in modes that don't need attachment to a preexisting process, i.e., targeting core files or new child processes only. If so, the dependency could go onto gdb and probably gdb-gdbserver instead of gdb-headless.

• does abrt pull it in

An ABRT plugin pulls in gdb-headless.

• how does this interact with SELinux?

Orthogonal.

• if gdb* is removed, does the more permissive config get removed as well?

In the post-Change world, if nothing but gdb required it, yama-ptrace-enable would become a leaf package. dnf autoremove would nuke it.

• how many fedora systems will get the secure profile effectively?

I know of no way of knowing this, lacking fedora rpm installation telemetry.

Well, I think the question in more detail was: we install abrt by default and that pulls in some gdb subset, does that path cause every user except those that explicitly go back in and remove abrt and it's dependencies to have the relaxed/developer setting. ie, does it make this change largely a no op for all the users with default installs?

Like others I wasn't aware of this ticket or the discussion thread. It seems the change process does no longer CC the relevant owners. It seems the "AI" just invents some plausible sounding names/nicks. Please don't use some AI which that doesn't work reliably. The same seems to have happened before. And it really wastes people's time.

I am not sure this ticket is the best place to discuss the change proposal yet again, but given there are questions here now lets do. I think Chris and Frank already answered most of them and the general answer is simple, yes, this is a compromise proposal, as fesco asked for last time, nobody gets their way :)

If you see this as some essential core security feature you are just not going to like this compromise proposal. See it as a hardening thing that might be helpful to slow down an attacker (but if your adversary already has full code execution, they'll find some trick to observe your other processes). Ideally we would have something that could be enable/disable much more granular, but we haven't. As proposed this is just a simple way for a debug/admin tools that need it to indicate the default should be for the package to work out of the box. Compare it with installing a sysctl file to get a higher file descriptor count. It just makes some debug/admin tools work out of the box. So a user doesn't need elevated privileges to run them (which in itself would be a security issue). It might indeed keep the status quo if the default install pulls in one of these debug/admin tools like gdb. But at least users could create an install that wouldn't.

Well, I think the question in more detail was: we install abrt by default and that pulls in some gdb subset, does that path cause every user except those that explicitly go back in and remove abrt and it's dependencies to have the relaxed/developer setting. ie, does it make this change largely a no op for all the users with default installs?

"depends". ABRT pulls in gdb-headless. We could opt to suggest to the gdb team to have the new ptrace dependency associate with the main gdb package, and not gdb-headless. In this case, having only ABRT+deps should not activate this override.

Is there an ABRT person we can talk with to confirm / check?

I tried to test this, and as far as I can tell, abrt does not need kernel.yama.ptrace_scope = 0 to work. I added an override for kernel.yama.ptrace_scope = 1 to my Fedora install and I am able to use abrt to generate backtraces from coredumps without problems.

Confirmed that the ABRT "make check" code passes with both 0 and 1 in /proc/sys/kernel/yama/ptrace_scope, suggesting it does not rely on gdb -p $PID that would require the override/dependency.

For the sake of completeness: I work with kernel.yama.ptrace_scope = 2 (so more restrictive than 1) since the first discussion in discourse, so I guess that's now about 6 months or so. I just took info of abrt of a recent crash, and created a backtrace:

py0xc3@fedora:~$ abrt info 2877d57
Id            2877d57  
Component     spectacle  
Count         1  
Time          2026-03-09 01:08:52  
Command line  /usr/bin/spectacle --dbus  
Package       spectacle-1:6.6.2-1.fc43  
User id       1000 (py0xc3)  
Path          /var/spool/abrt/ccpp-2026-03-09-01:08:52.573702-76255
py0xc3@fedora:~$ man abrt
py0xc3@fedora:~$ abrt retrace 2877d57
Generating backtrace
Backtrace is generated and saved, 203196 bytes
py0xc3@fedora:~$ 

The gdb proces that has been invoked by the retrace was: /usr/libexec/gdb -batch -ex "set debuginfod enabled on" "" -ex "file /usr/bin/spectacle" -ex "core-file ./coredump" -ex "thread apply all -ascending backtrace full 1024" -ex "info sharedlib" -ex "print (char*)__abort_msg" -ex "print (char*)__glib_assert_msg" -ex "info all-registers" -ex disassemble

Looks good to me.

I believe this was approved at the March 10 meeting. Is there some holdup marking this closed and the Change "accepted" ?

@salimma did you miss this ticket when doing the post-meeting processing?

This is APPROVED (+5, 1, -1) in the March 10 meeting: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/GIF6CE6C55PQW3XHODGKYCKCNJNZO4VO/

* TOPIC: #3569 Change: Restrict_ptrace_by_default  (@salimma:fedora.im,
18:30:10)
    * AGREED: Restrict ptrace by default is approved for F45 (+5, 1, -
1) (@salimma:fedora.im, 18:37:36)