From: Oleg Nesterov <oleg@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
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 22:01:53 +0200 [thread overview]
Message-ID: <20240804200153.GC27866@redhat.com> (raw)
In-Reply-To: <CAHk-=wjr0p5CxbC-iGEznupau936D24iotTZi7eFXqgKX-otbg@mail.gmail.com>
On 08/04, Linus Torvalds wrote:
>
> 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.
I meant, the dumping thread can't exit until the dumper reads the data
from stdin or closes the pipe. Until then the damper can read /proc/pid/mem
and do other things.
> > 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.
Well. If, say, selinux disables ptrace, then ptrace_attach() in this
patch should also fail.
But if some setups disable sys_ptrace() as a system call... then yes,
I didn't know that.
> THAT is why I don't like it. ptrace() is *dangerous*.
And horrible ;)
> Just adding some implicit tracing willy-nilly needs to be something
> people really worry about.
Ok, as I said I won't insist.
Oleg.
next prev parent reply other threads:[~2024-08-04 20:02 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
2024-08-04 20:01 ` Oleg Nesterov [this message]
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=20240804200153.GC27866@redhat.com \
--to=oleg@redhat.com \
--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=torvalds@linux-foundation.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.