From: Stephen Hemminger <stephen@networkplumber.org>
To: Christian Brauner <brauner@kernel.org>
Cc: linux-fsdevel@vger.kernel.org, "Jann Horn" <jannh@google.com>,
"Daniel Borkmann" <daniel@iogearbox.net>,
"Kuniyuki Iwashima" <kuniyu@amazon.com>,
"Eric Dumazet" <edumazet@google.com>,
"Oleg Nesterov" <oleg@redhat.com>,
"David S. Miller" <davem@davemloft.net>,
"Alexander Viro" <viro@zeniv.linux.org.uk>,
"Daan De Meyer" <daan.j.demeyer@gmail.com>,
"David Rheinsberg" <david@readahead.eu>,
"Jakub Kicinski" <kuba@kernel.org>, "Jan Kara" <jack@suse.cz>,
"Lennart Poettering" <lennart@poettering.net>,
"Luca Boccassi" <luca.boccassi@gmail.com>,
"Mike Yuan" <me@yhndnzj.com>, "Paolo Abeni" <pabeni@redhat.com>,
"Simon Horman" <horms@kernel.org>,
"Zbigniew Jędrzejewski-Szmek" <zbyszek@in.waw.pl>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-security-module@vger.kernel.org,
"Alexander Mikhalitsyn" <alexander@mihalicyn.com>,
"Serge Hallyn" <serge@hallyn.com>
Subject: Re: [PATCH v8 0/9] coredump: add coredump socket
Date: Tue, 20 May 2025 12:28:38 -0700 [thread overview]
Message-ID: <20250520122838.29131f04@hermes.local> (raw)
In-Reply-To: <20250516-work-coredump-socket-v8-0-664f3caf2516@kernel.org>
On Fri, 16 May 2025 13:25:27 +0200
Christian Brauner <brauner@kernel.org> wrote:
> Coredumping currently supports two modes:
>
> (1) Dumping directly into a file somewhere on the filesystem.
> (2) Dumping into a pipe connected to a usermode helper process
> spawned as a child of the system_unbound_wq or kthreadd.
>
> For simplicity I'm mostly ignoring (1). There's probably still some
> users of (1) out there but processing coredumps in this way can be
> considered adventurous especially in the face of set*id binaries.
>
> The most common option should be (2) by now. It works by allowing
> userspace to put a string into /proc/sys/kernel/core_pattern like:
>
> |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h
>
> The "|" at the beginning indicates to the kernel that a pipe must be
> used. The path following the pipe indicator is a path to a binary that
> will be spawned as a usermode helper process. Any additional parameters
> pass information about the task that is generating the coredump to the
> binary that processes the coredump.
>
> In the example core_pattern shown above systemd-coredump is spawned as a
> usermode helper. There's various conceptual consequences of this
> (non-exhaustive list):
>
> - systemd-coredump is spawned with file descriptor number 0 (stdin)
> connected to the read-end of the pipe. All other file descriptors are
> closed. That specifically includes 1 (stdout) and 2 (stderr). This has
> already caused bugs because userspace assumed that this cannot happen
> (Whether or not this is a sane assumption is irrelevant.).
>
> - systemd-coredump will be spawned as a child of system_unbound_wq. So
> it is not a child of any userspace process and specifically not a
> child of PID 1. It cannot be waited upon and is in a weird hybrid
> upcall which are difficult for userspace to control correctly.
>
> - systemd-coredump is spawned with full kernel privileges. This
> necessitates all kinds of weird privilege dropping excercises in
> userspace to make this safe.
>
> - A new usermode helper has to be spawned for each crashing process.
>
> This series adds a new mode:
>
> (3) Dumping into an AF_UNIX socket.
>
> Userspace can set /proc/sys/kernel/core_pattern to:
>
> @/path/to/coredump.socket
>
> The "@" at the beginning indicates to the kernel that an AF_UNIX
> coredump socket will be used to process coredumps.
>
> The coredump socket must be located in the initial mount namespace.
> When a task coredumps it opens a client socket in the initial network
> namespace and connects to the coredump socket.
There is a problem with using @ as naming convention.
The starting character of @ is already used to indicate abstract
unix domain sockets in some programs like ss.
And will the new coredump socekt allow use of abstrace unix
domain sockets?
next prev parent reply other threads:[~2025-05-20 19:28 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-16 11:25 [PATCH v8 0/9] coredump: add coredump socket Christian Brauner
2025-05-16 11:25 ` [PATCH v8 1/9] coredump: massage format_corename() Christian Brauner
2025-05-16 11:25 ` [PATCH v8 2/9] coredump: massage do_coredump() Christian Brauner
2025-05-16 11:25 ` [PATCH v8 3/9] coredump: reflow dump helpers a little Christian Brauner
2025-05-16 11:25 ` [PATCH v8 4/9] coredump: add coredump socket Christian Brauner
2025-05-16 14:33 ` Jann Horn
2025-05-22 23:25 ` Paul Moore
2025-05-23 0:59 ` Randy Dunlap
2025-05-16 11:25 ` [PATCH v8 5/9] pidfs, coredump: add PIDFD_INFO_COREDUMP Christian Brauner
2025-05-16 14:37 ` Jann Horn
2025-05-16 11:25 ` [PATCH v8 6/9] coredump: show supported coredump modes Christian Brauner
2025-05-16 11:25 ` [PATCH v8 7/9] coredump: validate socket name as it is written Christian Brauner
2025-05-16 11:25 ` [PATCH v8 8/9] selftests/pidfd: add PIDFD_INFO_COREDUMP infrastructure Christian Brauner
2025-05-16 11:25 ` [PATCH v8 9/9] selftests/coredump: add tests for AF_UNIX coredumps Christian Brauner
2025-05-20 19:28 ` Stephen Hemminger [this message]
2025-05-21 0:41 ` [PATCH v8 0/9] coredump: add coredump socket Kuniyuki Iwashima
2025-05-21 0:54 ` Jann Horn
2025-05-21 15:12 ` Christian Brauner
2025-05-21 11:12 ` Christian Brauner
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=20250520122838.29131f04@hermes.local \
--to=stephen@networkplumber.org \
--cc=alexander@mihalicyn.com \
--cc=brauner@kernel.org \
--cc=daan.j.demeyer@gmail.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=david@readahead.eu \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=jack@suse.cz \
--cc=jannh@google.com \
--cc=kuba@kernel.org \
--cc=kuniyu@amazon.com \
--cc=lennart@poettering.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=luca.boccassi@gmail.com \
--cc=me@yhndnzj.com \
--cc=netdev@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=pabeni@redhat.com \
--cc=serge@hallyn.com \
--cc=viro@zeniv.linux.org.uk \
--cc=zbyszek@in.waw.pl \
/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;
as well as URLs for NNTP newsgroup(s).