I can't change the title: it's a F44 change proposal ("F44 Change Proposal: Restrict ptrace for unprivileged users to child processes to match kernel default [SystemWide]"). It seems the AI has the same issues at pagure as with the mailing list ("_" rather than spaces).

+1

This is APPROVED after four weeks with (+1, 0, -0) votes.

Did the fesco discussion include the matters raised here: ? Was there a fesco discussion?

https://discussion.fedoraproject.org/t/f44-change-proposal-restrict-ptrace-for-unprivileged-users-to-child-processes-to-match-kernel-default-systemwide/174493/8

We need guidance as to whether other packages should or may or should not or whatever an equivalent sysctl file.

I missed this was added to the Fesco agenda or I would have attended the meeting. I am a little surprised this was approved when both the mailinglist as the forum discussion were overwhelmingly negative (more than 50% was strongly opposed). Especially from the users and maintainers of the affected packages. Does this mean that Fesco is ordering the current maintainers to drop their policy, package, dependencies and requires? Something I am strongly against. Since I don't believe this proposal provides a valid alternative and person proposing this hasn't been willing to help work on one.

I think we've hit an edge case here where most of FESCo wasn't even here to vote for it.

mjw, I don't think the mailing list was overwhelming negative. Actually, skimming over all three debates, my perception is the opposite, with several people changing opinion when finding out this is not the end of the world for developers, though there are several reservations of course, and a few -1 too.

As far as it concerns discourse, the again-repeated poll after the exhausting discussions contains just a handful of users (8 users) at this time, who, based on posts in Discourse, I assume are the same with -1 (4 users) as those in the mailing list and here. That's exactly 50% btw, not more. The enforced adjustment of titles also might have made its impact on the Discourse audience. You might want to review the initial Discourse poll, as it has 23 user votes rather than just 8, with 74% in favor.

That surely is not necessarily relevant, and I am quite sure it is not representative just like the other polls, nor do I expect FESCo to consider it binding or so, but please don't count your own vote twice and exclude everyone who voted/argued differently.

If/when this is accepted is not my decision to make. I will be back in a few days and take for granted what I will be provided with. Happy new year everyone btw ;)

I think we've hit an edge case here where most of FESCo wasn't even here to vote for it.

Aha, OK. Can we then schedule a new vote/discussion? I am happy to attend and explain the current policy, technical issues and alternatives.

I think we've hit an edge case here where most of FESCo wasn't even here to vote for it.

Not entirely unlike the -fomit-frame-pointer re-vote a few years ago where it was reopened literally between christmas and new year's. #2923.

Note: This ticket was filed on Dec. 9, i.e. two weeks before the Christmas break. As the person who volunteered to handle tickets over the holidays, I intentionally kept this ticket open for twice as long as actually required (four weeks!), to give more time for feedback or negative votes because there was a lot of feedback on the mailing list and on the discussion forum.

The frame-pointer proposal comparison is also quite apples-to-oranges: The original rejection of that proposal happened in a sync meeting on IRC on Nov. 29 2022 (with seven votes cast), and the decision was revisited in another sync IRC meeting where EIGHT (!) fesco members were present and cast their votes. "where most of FESCo wasn't even here to vote for it." is, quite obviously, wrong.

Note: This ticket was filed on Dec. 9, i.e. two weeks before the Christmas break. As the person who volunteered to handle tickets over the holidays, I intentionally kept this ticket open for twice as long as actually required (four weeks!), to give more time for feedback or negative votes because there was a lot of feedback on the mailing list and on the discussion forum.

Yeah, understood. It also didn't help that the first Fesco meeting this year where this was on the agenda didn't reach quorum so it never was really discussed or voted on.

Lets just put it on the next Fesco agenda and I'll make time to attend so it can be properly discussed.

I'm +1 to discussing this in an upcoming meeting. We have had holiday breaks + FESCo vote delays at the end of 2025 so this wasn't really the best time to get FESCo members involved.

I'm +1 to discussing this in an upcoming meeting

I have no problem with that. This is not time critical after all. I would prefer this to be postponed to F45 and implemented and communicated properly, rather than implement it in a hurry and causing confusion or the need to revert.

I'll make time to attend so it can be properly discussed

However, my suggestion would be to leave (this topic at least) to be discussed by FESCo-only: the 3 (I think even 4?) discussions in the mailing list about this (plus the discussion in the 4 Discourse topics) should have covered every perspective and implication of this, including implications of suggested alternatives (e.g., SELinux). The later discussions already contained a lot of highlighting of the own preference by repetition, including repeating what has been already proven to be not applicable / not work in earlier discussions about it (I am not referring to anyone or any side in specific here but mean that in general).

If an argument is worth to be mentioned, I have no doubt it is contained in the existing discussions, put in context of its implications by whoever knows one. If an argument has not been put forward in all this time and all these discussions, it might be questioned why.

On one hand, I don't feel the need to join such a meeting (and might not have the time anyway) as again highlighting own points through repetition (then in a much more limited evaluation of implications compared to the mailing list or Discourse) doesn't feel a useful use of time. On the other hand, adding only one perspective doesn't feel constructive too, especially if put forward isolated from analyzing implications in the collaborative setting of the mailing list or so.

I trust that FESCo members are able to review what needs to be reviewed, and make an educated decision about it. So I would ask both sides to respect their (and our) time and leave them to the data of the many discussions... If FESCo thinks that more data or evaluation is necessary, I'm sure they will find out themselves and re-open a discussion among everyone, in an open collaborative setting in which everyone can contribute their knowledge.

From today's meeting:

!agreed REVERTED (+5, 3, 0) The slightly unusual in-ticket vote is invalidated. The topic will be discussed again next week.

@py0xc3 As things are right now, this change doesn't make sense. In the Scope section, you listed that you'll just add an override in systemd.rpm. The removal of elfutils-default-yama-scope is left to be done by someone else without a clear plan. Without a clear plan, this is likely to never get done, and we'll end up with three files fighting for the same setting. Thus, -1 for the current proposal.

(There is also the problem that the Change text is a wall'o'text that mixes objective and subjective statements, mixes topics, and is in general too long.)

Sorry, but this needs to be adjusted:
1. Discuss and cooperate with the maintianers of elfutils-default-yama-scope to get rid of the package (by removing it from the spec file and adding Obsoletes somewhere)
2. Have one file with the new setting and some documentation around it
3. Also cater to developers, so make sure that the file has clear instructions how to both temporarily and permanently allow unprivileged ptrace.

(So this is really more about removing things. Nothing new is needed.)

Thanks for the feedback. However, there are a few points in your statement that are not true or not possible, and make your suggestions in the end impossible to implement, so just to clarify:

In the Scope section, you listed that you'll just add an override in systemd.rpm

False. I prepare the file 10-harden-yama-ptrace.conf, without enabling or installing it (see the PR). This is to make it easier for those who want the setting 2 to use it, and to have a file who makes them aware of the possibility: at the moment, the only documentation we have about ptrace_scope is the (disabled / not installed) file 20-yama-ptrace.conf, which was there already before. So I align with the "current documentation" of setting 0 and add one for setting 2. Assuming the setting 1 is the default.

The removal of elfutils-default-yama-scope is left to be done by someone else without a clear plan

The maintainers rejected to discuss anything that goes in the direction of removing the file but only alternatives. All alternatives I have seen either do not fulfill the same purpose or impose invasive means that have already proven to not work (e.g., SELinux confined users, which make users to choose between no longer being able to share files with other users/people or to break video conferencing, in both cases with regular broken policies with the need to write bug reports against selinux-policy given that most maintainers do not work on this -> we work on this for 2 years and it takes sometimes weeks after release updates to get the policies of that adjusted, virtualization is regularly broken for months in SELinux confined users).

The change PR to raise awareness and create a discussion was the only choice I had left. Given the system default, the package needs to be just removed as dependency and then removed itself. I cannot do that, the maintainers reject to discuss this variant. And I cannot implement the removal of this package myself.

1. Discuss and cooperate with the maintianers of elfutils-default-yama-scope to get rid of the package (by removing it from the spec file and adding Obsoletes somewhere)

Again, the package does not use or touch the spec file... This is the major confusion of this package: the package creates another config file (10-default-yama-scope.conf) and enables/installs that new one. It leaves the spec file untouched and it leaves the intended 20-yama-ptrace.conf file untouched (-> intended for disabling ptrace_scope for users who want it): 20-yama-ptrace.conf remains disabled and not used by the package. This is what confused you in the PR and Fabio and me in the original discussion.

It is not possible to remove the package's override of the default by any changes to the spec file except we add an override to do the override of the override, which I considered a bad and even more confusing practice (default -> package overrides default -> systemd spec overrides override).

So if people use the only documentation Fedora has itself (which is the file 20-yama-ptrace.conf), they will not find out why ptrace_scope is disabled.

As I said, maintainers reject to discuss anything that includes removing the package. So your argument about this equals a permanent -1. Please be aware of that.

1. Have one file with the new setting and some documentation around it

The package already makes it two, which is why I would consider that even if everyone would want to keep ptrace_scope disabled, I suggest to remove the package and just enable the default way: make 20-yama-ptrace.conf installed by default.

The new setting does not need any file (-> it is the kernel default), but only removal of the package.

The additional file I create is not for the new default (which is the kernel default) but for users who want more security with setting 2 but do not get any documentation / hint about how to do it on Fedora. I provide this new file the same way Fedora already provides the counter-part to disable ptrace_scope: 20-yama-ptrace.conf is provided that way, and I align with it in 10-harden-yama-ptrace.conf.

I am happy to leave out the file 10-harden-yama-ptrace.conf if that leads to a +1 because it is not necessary to get back the kernel default, but in that case, we do not need any change to systemd at all: removing the package will do the job. It's sole purpose is to override the kernel default with creating+enabling/installing a new config file, and it does so without touching the spec file and without touching the existing config file (20-...) that used to be intended for that purpose.

If you want no unnecessary file that is disabled by default, we need to get another proposal to remove the existing 20-yama-ptrace.conf. I did not introduce it. And it is disabled both with and without the package.

Also cater to developers, so make sure that the file has clear instructions how to both temporarily and permanently allow unprivileged ptrace.

That's in the PR, isn't it? I contained in the files, and in the release notes. Both based on feedback from the developers in the discussions (the argument was that release notes are most important). Not sure what further to do here?

we'll end up with three files fighting for the same setting

If you consider disabled files (existing for users who need them but not installed/enabled by default) as part of the fight, I did not introduce this fight but the package, starting it with two files. If you do not consider disabled files as part of the fight, then there is no fight, neither before nor after my change. However, having two files for the very same purpose (which can be also called a fight) is introduced by the package, and this is one thing I want to get rid of with my proposal because this has caused already much confusion and makes it harder for users to change their system default (in whatever direction).

Just in case this is the source of the confusion: please differentiate between my file 10-harden-yama-ptrace.conf and the package's file 10-default-yama-scope.conf.

I agree with zbyszek on one point - the situation is already complicated enough, adding more things doesn't make this better.

The actual crux of the issue seems to be:

Given the system default, the package needs to be just removed as dependency and then removed itself. I cannot do that, the maintainers reject to discuss this variant. And I cannot implement the removal of this package myself.

While this is not something we would do lightly, FESCo could (theoretically) approve a Change proposal that includes overriding package maintainer preferences. Given the current situation, it appears that we either need to do that, or accept keeping the (suboptimal, IMO) status quo.

100%.

the situation is already complicated enough, adding more things doesn't make this better.

Good point indeed . A compromise might be to not implement the file 10-harden-yama-ptrace.conf (as mentioned in the proposal, this is only the minor part of the proposal, not a dependency of the major part, which is to reset the kernel default).

Not implementing 10-harden-yama-ptrace.conf would make my PR unnecessary: then, the only remaining thing to do is to remove the package elfutils-default-yama-scope. Removing the package would automatically reset the default of the kernel because the file 10-default-yama-scope.conf would then not be created by the package and then enabled/installed by it (which is the sole purpose of the package).

In that case, we would not touch the file 20-yama-ptrace.conf but leave it as a simple means for developers who want ptrace_scope disabled permanently. That said, I would be happy to still update the file comments of 20-yama-ptrace.conf to be a little more precise and more compliant to the Kernel Docs (this would mean I change the PR to only change the comments in that file as it's the only Docs on Fedora about this at all; I would leave it mostly with my updates but remove any reference to 10-harden-yama-ptrace.conf). Of course that's a minor thing too. So not doing any PR is ok too, and as I said, a PR is no dependency for the major change (-> kernel default of ptrace_scope = 1 -> this is achieved already by the systemd.spec the way it is, if not overwritten by the package later)

PS: I would not to use the "edit" function for pagure comments too much (other than to fix typos or add missing punctuation, maybe). For example, people who try to keep up with the discussion via email only get the initial text, but don't get followup notifications on edits. It's also hard to tell when a comment is marked as "edited" whether it's "basically the same, don't need to read it again" or "something has changed, I should read this again". In my experience this just leads to confusion, because people might respond to old versions of the comment without realizing.

Minor thought for tomorrow: If you come to the conclusion that you want to leave ptrace_scope disabled (0), you might still consider to remove the package and then disable ptrace_scope instead with the "formally default way" by enabling 20-yama-ptrace.conf: one line in systemd.spec. It is very confusing for users who want to enable ptrace_scope to 1, or wonder why it is disabled (0) on default installations: the only documentations says it is enabled by default with 1 (because 20-yama-ptrace.conf is disabled by default) but it is 0, whereas it is not a trivial task to find out about the package and its implications if ptrace_scope (or related needs) is the starting point of the investigation.

This would avoid the fight of files you talked about, make it comprehensible for users who want to impact ptrace_scope (or even falsely assume the condition of ptrace_scope due to documentation without checking its actual state), and it would align the "sole documentation" with the actual state. Just as an alternative if you want to keep ptrace_scope disabled at 0. This would not impact users or developers at all, as the outcome of the system would be the same: ptrace_scope = 0.

This issue will be discussed at the next meeting on 2026-01-20

I agree this feature isn't ready just given all the new ideas to implement in this ticket.

The discussion in this ticket has the same issue as all the previous discussions and the change proposal text itself. It is a massive wall of text that mixes fact, desires and opinions of one person. It also misrepresents the current policy, package and requirements.

Any discussion about the current policy or how to resolve the goals of having a default-yama-scope that works for the existing package (dependencies) has just been dismissed by the change proposal owner as something he is not interested in and as work that someone else has to do.

This doesn't have to be done as some kind of us (users) versus them (package maintainers, developers) trying to produce a lot of text to argue "your side".

I would end my project at this time and enter a passive role for whatever comes next. I think trying to work "on par" has potential for further escalations given the unchanged context and yesterday's FESCo decision, so I subordinate my role to allow a development. Also, I mentioned already before the first proposal, and above in this one again: I proposed this one because I saw the need to bring this to discussion, but I didn't and don't have much time to invest here, it was already time I had to take from elsewhere. It became three proposals, and with the remaining possibilities in mind and yesterday's decision, it is now asked to get much deeper into details potentially unrelated to the proposal and not part of my regular work (thus I need to invest more time).

FESCo did not decide if they want 0 or 1, which leads back to the repeating original situation: for me, it is not collaboration if the discussion begins with the obligation to accept that ptrace_scope must remain disabled systemwide, and gdb/strace-related package-dependency-only (etc) is not an option. I wanted to collaborate to contain all opinions appropriately in the proposal and reached out, and the result was that my draft has been rewritten to an essay about why I am wrong and that Fedora is not a user appliance distro, introducing ptrace_scope's potential for "user protection" is a "claim": in short, rewritten into a proposal that argues for being rejected. My revert of this has been an argument for my incapability to collaborate in every debate since. The problem is I understand the maintainers to some extent, and this way of exchanging does not add value to anyone of us, and I see no value in repeating this -> this is actually not criticism on the maintainers, whom I can understand, and whose perspective I still find important to consider, but criticism on the competitive/destructive context we ended up in (neither's fault imho), and enforcing to repeat this is not useful. Putting forward a proposal was intended to end this by neutral entities deciding in either direction by reviewing both perspectives and then go on, not to repeat the same situation again.

I have facilitated a discussion and rationalization of the issue (major goal achieved :) and hope it facilitates some useful developments in subsequent proposals, but I don't see the need for an active role from me because:

If ptrace_scope remains disabled, it is a new project, and I by rule do not engage in low-level software development (and related dependencies) for others because it's not my domain for long (and never much around debugging and C): I cannot provide the QA and reliable time investment in this field that I expect when users depend on it. There are more experienced people for that. I doubt that an approach of different adjustments here and there (one variant put forward; yes I simplify, my bad:) can replace a holistic explicit security approach as the well-reviewed/understood ptrace_scope, but if so, others (likely including the two maintainers) have more expertise to evaluate how to implement anything related to these ideas because it enters a different scope, and as I said, it's a new project, may it add security in my proposal's area or in other areas. I add value more effectively in other areas. About the SELinux approach, let's not consider it again: there is sufficient evidence and documentation (all the reports of the SELinux team of the confined users SIG and many bug reports of confinement issues after updates), repeated many times why this cannot work as replacement -> I can't add more value here as well.

If ptrace_scope becomes enabled and we just want in advance that developers have a mitigation for themselves: sure, I was for that from the beginning but I had to get things started somehow. But again, there is no role for me here, as I cannot speak for devs nor represent their intersts. I can only wait for them to work on a useful mitigation, and then come up with the same proposal again: remove the package. That's it. Feel free to let me know if I shall create a 2-liner proposal afterwards, that's what I can do.

I don't see that I can contribute something efficient and effective to the remaining possibilities. The two maintainers might be well candidates for this, but I can at the best review the result and add my opinion about if I can verify if it equals ptrace_scope=1 or not. As mentioned, this does not change the fact that I am always happy to review ANY PROPOSAL and add my thoughts if anyone wants my expertise, but my role in this would be still more a passive one.

So I would remain passive about this from now on, please close this ticket, and if anyone has something for me to give feedback on, feel free to let me know. I'll be happy to do so. I cannot guarantee an approval though. But this can also mean whatever comes next has left the scope I feel fully qualified to argue in without investing too much time I need elsewhere, and I would remain in any case with a +1 or 0, not -1. The latter will be FECSo's decision if applicable.

I don't think yesterday's decision considers the preceding of this proposal and its predecessors, but I cannot blame anyone for not getting into this :) What this has developed to complies even to my definitions of walls of texts :)

So I hope that step makes sense, it is intended to add value and give the maintainers the freedom (and time) they need to create any value from the debate, in this or other areas :)

We decided in the meeting to reject the proposal, and ask @py0xc3 , @mjw and @fche to figure out a new proposal for F45 (0, 0, -9)

FTR, as suggested/requested, I've started drafting a compromise version of py0xc3's proposal.

https://fedoraproject.org/wiki/Changes/Restrict_ptrace_by_default

Thanks. Let me know once there is something ready I am asked to review / give feedback :thumbsup:

Thank you. Some quick comments:

Add Requires: yama-ptrace-enable

Please make that just Recommends.

Also, in systemd there's a file installed as documentation that contains a lengthy explanation for kernel.yama.ptrace_scope. We should probably drop that and move/merge that description to the file in the new package.

I forgot to add: this is such a small change that I'd be happy to push it in for F44 already. No need to wait for half a year for a (small) security tightening.

We should probably drop that and move/merge that description to the file in the new package.#

That's indeed a good point. Vice versa to my idea above (the "Minor thought for tomorrow" comment), but with the same result: If we stick with having a package, we should remove the file 20-yama-ptrace.conf at all to avoid the redundancies and inconsistencies. Having both is the confusing thing I talked about. Since any accepted variant seems to go in the direction of doing any ptrace_scope adjustment with a package, removing the file is a good idea.

I can do that PR (so just to remove 20-yama-ptrace.conf) as part of the proposal (or should I do this right now, as independent measure?)

this is such a small change that I'd be happy to push it in for F44 already

Give me a thumbs up if you refer to removing the file 20-yama-ptrace.conf. Then I can prepare the PR in the next days. As you say, that's a minor thing to do.

I forgot to add: this is such a small change that I'd be happy to push it in for F44 already. No need to wait for half a year for a (small) security tightening.

Not so small since the compromise proposal needs all debugger-like packages to add the new dependency to get the sysctl file back. Probably too short notice now.

Are you sure? The file 20-yama-ptrace.conf seems inactive in both settings, with and without elfutils-default-yama-scope. The package elfutils-default-yama-scope seems to create+enable its own file: 10-harden-yama-ptrace.conf. That was the confusion the initial discussion fell prone to, because the file 20-yama-ptrace.conf is inactive/disabled on Fedora but the condition of the system (ptrace_scope) is as if the file is enabled (due to the impact of 10-harden-yama-ptrace.conf).

I'm just asking for my understanding of your point, there is surely no need for time-critical PR, if any PR at all :)

(Sorry I misunderstood. The /usr/share/doc/systemd/20-yama-ptrace.conf is superfluous, yes, relative to the very similar but effective /usr/lib/sysctl.d/10-default-yama-scope.conf .)

Sounds good. I will then prepare a PR this week to get rid of 20-yama-ptrace.conf.

@py0xc3 ok please check the above proposed compromise Change. It has some missing documentation details etc., but the basic idea is fine. I don't really want to spam this ticket with discussion about it, but if you have an objection to what's in there, please contact me via email and see if we can hash it out.

@zbyszek PR opened: https://src.fedoraproject.org/rpms/systemd/pull-request/232

@fche thanks for the new draft! +1 for the approach, I just did a minor change to text details that I hope is ok for everybody (no change to your approach!). See my email.

Lets let this ticket sleep. If there is more, please email or Discourse. I am not regularly on the devel mailing list.