[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wjr0p5CxbC-iGEznupau936D24iotTZi7eFXqgKX-otbg@mail.gmail.com>
Date: Sun, 4 Aug 2024 12:18:05 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Oleg Nesterov <oleg@...hat.com>
Cc: Brian Mak <makb@...iper.net>, "Eric W. Biederman" <ebiederm@...ssion.com>, Kees Cook <kees@...nel.org>,
Alexander Viro <viro@...iv.linux.org.uk>, Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>,
"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>, "linux-mm@...ck.org" <linux-mm@...ck.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH] piped/ptraced coredump (was: Dump smaller VMAs first
in ELF cores)
On Sun, 4 Aug 2024 at 11:53, Oleg Nesterov <oleg@...hat.com> wrote:
>
> Apart from SIGKILL, the dumper already has the full control.
What do you mean? It's a regular usermodehelper. It gets the dump data
as input. That's all the control it has.
> And note that the dumper can already use ptrace.
.. with the normal ptrace() rules, yes.
You realize that some setups literally disable ptrace() system calls,
right? Which your patch now effectively sidesteps.
THAT is why I don't like it. ptrace() is *dangerous*. It is very
typically one of the things that people limit for various reasons.
Just adding some implicit tracing willy-nilly needs to be something
people really worry about.
Linus
Powered by blists - more mailing lists