From: Linus Torvalds <torvalds@linux-foundation.org>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Brian Mak <makb@juniper.net>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Kees Cook <kees@kernel.org>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH] piped/ptraced coredump (was: Dump smaller VMAs first in ELF cores)
Date: Sun, 4 Aug 2024 12:18:05 -0700 [thread overview]
Message-ID: <CAHk-=wjr0p5CxbC-iGEznupau936D24iotTZi7eFXqgKX-otbg@mail.gmail.com> (raw)
In-Reply-To: <20240804185338.GB27866@redhat.com>
On Sun, 4 Aug 2024 at 11:53, Oleg Nesterov <oleg@redhat.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
next prev parent reply other threads:[~2024-08-04 19:18 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-02 22:37 [PATCH v2] binfmt_elf: Dump smaller VMAs first in ELF cores Brian Mak
2024-08-03 3:25 ` Eric W. Biederman
2024-08-04 15:23 ` [RFC PATCH] piped/ptraced coredump (was: Dump smaller VMAs first in ELF cores) Oleg Nesterov
2024-08-04 17:47 ` Linus Torvalds
2024-08-04 18:53 ` Oleg Nesterov
2024-08-04 19:18 ` Linus Torvalds [this message]
2024-08-04 20:01 ` Oleg Nesterov
2024-08-05 17:56 ` Brian Mak
2024-08-05 19:10 ` Linus Torvalds
2024-08-05 21:27 ` Brian Mak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAHk-=wjr0p5CxbC-iGEznupau936D24iotTZi7eFXqgKX-otbg@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=brauner@kernel.org \
--cc=ebiederm@xmission.com \
--cc=jack@suse.cz \
--cc=kees@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=makb@juniper.net \
--cc=oleg@redhat.com \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox