But this vulnerability doesn't affect any Fedora release. Why should we permit it?

All linux kernels are vulnerable to the general type of attack described, so we think the most responsible thing to do is to disable by default this feature that only a small percentage of users use. We can expect all OS providers including Fedora to not urgently fix future moderate severity vulnerabilities in the ext4 filesystem similar to the one referred to in CVE-2023-30549, so it is safer to not expose systems to that type of attack. Users can use the non-privileged version of the same feature or, if they still want the setuid-root form are willing to live with the risk, they can re-enable the "allow setuid-mount extfs" option.

There is also value in having the same default behavior on all OS platforms; why should Fedora be the exception?

What users would be impacted by this change and how frustrating would that be? In the linked ticket, the sentence:

Most users don't use this feature, but a significant minority does.

Is confusing. I would like some data on what users use this feature. "significant minority" are opposing ideas. I don't think FESCo can make a decision without understanding what the impact to users would be and that information is not provided.

I'm sorry about that. My guess is that it might be 5 to 10% of the users. It's small a percentage, but I do sometimes see questions about it.

By contrast, I hardly ever see any questions or bug reports from people on Fedora, so my guess is there are very few people who actually use apptainer on Fedora at all. For those who are on Fedora they almost certainly will have unprivileged user namespaces available, so they could use the unprivileged mode.

I don't know enough about this area to have an informed opinion. I hope other FESCo members coalesce around some decision so I can follow their lead ;)

If this doesn't get resolved earlier, let's discuss it at the next meeting.

Pardon the comment from the peanut gallery, but I think the best solution would be for @dwd to implement this as a Fedora 39 self-contained change proposal. Because this vulnerability doesn't affect current Fedora releases, pushing this breaking change to Fedora 37 and 38 would not be justified. The EPEL Steering Committee's decision to allow the breaking change in EPEL branches should have no bearing on what happens in Fedora branches.

+1 to the peanut gallery comment

What is a "self-contained change proposal"? Is any kind of change proposal needed to update only rawhide?

I disagree that this vulnerability doesn't affect Fedora releases, since the attack method described in CVE-2023-30549 applies everywhere, but I don't feel strongly about updating f37 and f38 since I don't think it will affect many users. I will send a followup message to the apptainer announce list asking any Fedora users to comment in this issue, if there are those that care.

See https://docs.fedoraproject.org/en-US/program_management/changes_policy/ and https://docs.fedoraproject.org/en-US/program_management/changes_guide/

I disagree that this vulnerability doesn't affect Fedora releases

The apptainer CVE (CVE-2023-30549) states that the vulnerability exists on "older operating systems" where a kernel CVE (CVE-2022-1184) has not been patched. It specifically mentions RHEL 7. The kernel CVE was fixed in the upstream kernel 5.17.14, and was also backported to RHEL 8 and 9. Fedora 37 and 38 have always shipped a newer kernel than that and are thus not affected.

The original advisory also makes it clear that CVE-2022-1184 is an example of a general problem that vendors treat such CVEs as low urgency and delay patches of even current supported operating systems until their next major release when the vulnerabilities or low or moderate severity. It's not only about the one CVE. Fedora does not update the kernel in their older supported releases for low or moderate severity vulnerabilities as soon as they are released, do they?

Our kernels get updated pretty much right after kernel.org makes a release.

Our kernels get updated pretty much right after kernel.org makes a release.

That would make a difference then, I agree. That is even the case in the oldest supported Fedora version? It keeps up with the latest kernel release?

Yes. As an example: just before F36 went EOL, it was updated to 6.2.15.

Ok then I'll withdraw this request and just update rawhide.