Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #87278 > unrolled thread

Bug#1025071: closing 1025071

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1025071: closing 1025071 Salvatore Bonaccorso <carnil@debian.org> - 2025-05-01 23:00 +0200
    Bug#1025071: closing 1025071 Salvatore Bonaccorso <carnil@debian.org> - 2025-05-03 13:40 +0200
      Bug#1025071: closing 1025071 Salvatore Bonaccorso <carnil@debian.org> - 2025-05-10 10:20 +0200

#87278 — Bug#1025071: closing 1025071

Moin Tobias,

Thanks for acting on the bug.

On Thu, May 01, 2025 at 05:42:41PM +0200, Tobias Fiebig wrote:
> 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?

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

[toc] | [next] | [standalone]

#87328

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).

Regards,
Salvatore

[toc] | [prev] | [next] | [standalone]

#87513

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web