Bug#1025071: closing 1025071
Hi Niklas,
On Sat, May 03, 2025 at 01:36:08PM +0200, Salvatore Bonaccorso wrote:
> 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,
>
> On Fri, May 02, 2025 at 10:01:19PM +0200, Niklas Sombert wrote:
> > 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.
>
> What you did was exactly was i was looking for (more below)
>
> > Salvatore Bonaccorso wrote:
> >
> > > 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.
> >
> > 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.
>
> 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.
>
> > > 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.
> >
> > Sorry, but this is a circular argument. "We're not doing it because we
> > haven't done it yet."
>
> 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).
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
Reply to: