lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87sfy47c7k.fsf@disp2133>
Date:   Thu, 16 Sep 2021 10:49:03 -0500
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     Sasha Levin <sashal@...nel.org>
Cc:     linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Ohhoon Kwon <ohoono.kwon@...sung.com>,
        Ingo Molnar <mingo@...nel.org>,
        "David S . Miller" <davem@...emloft.net>,
        Christian Brauner <christian.brauner@...ntu.com>,
        Alexey Dobriyan <adobriyan@...il.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH AUTOSEL 5.14 19/25] connector: send event on write to /proc/[pid]/comm

Sasha Levin <sashal@...nel.org> writes:

> On Wed, Sep 15, 2021 at 08:45:37AM -0500, Eric W. Biederman wrote:
>>Sasha Levin <sashal@...nel.org> writes:
>>
>>> From: Ohhoon Kwon <ohoono.kwon@...sung.com>
>>>
>>> [ Upstream commit c2f273ebd89a79ed87ef1025753343e327b99ac9 ]
>>>
>>> While comm change event via prctl has been reported to proc connector by
>>> 'commit f786ecba4158 ("connector: add comm change event report to proc
>>> connector")', connector listeners were missing comm changes by explicit
>>> writes on /proc/[pid]/comm.
>>>
>>> Let explicit writes on /proc/[pid]/comm report to proc connector.
>>
>>This is a potential userspace ABI breakage?  Why backport it?
>>
>>Especially if there is no one asking for the behavior change in
>>userspace?
>
> This sounds like a concern with the patch going upstream rather than
> going to stable? stable has the same policy around ABI changes such as
> upstream.

Let me say it another way.  This looks more like an evolution of the
functionality rather than a bug fix.

With something like this unless someone cares I don't think it should be
backported.  It is all risk and no benefit.

This is all doubly so because I think there are about 2 connector users
and connector is not especially good at the job it tries to fulfill.
It is for that exact reason that connector does not work in containers.
We couldn't find any users who cared.

After the fiasco with the rlimit/ucount changes getting backported
before they are even stable is that I am tired of saying about backports
meh whatever.

If there is no one who actually cares (which is what I learned about
autosel from the rlimit/ucount fiasco) it makes no sense to backport
things unless they really are bug fixes.

Backporting this just looks like senseless churn.

Eric

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ