From: Christian Brauner <brauner@kernel.org>
To: Kuniyuki Iwashima <kuniyu@amazon.com>
Cc: alexander@mihalicyn.com, bluca@debian.org,
daan.j.demeyer@gmail.com, davem@davemloft.net,
david@readahead.eu, edumazet@google.com, horms@kernel.org,
jack@suse.cz, jannh@google.com, kuba@kernel.org,
lennart@poettering.net, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, me@yhndnzj.com,
netdev@vger.kernel.org, oleg@redhat.com, pabeni@redhat.com,
viro@zeniv.linux.org.uk, zbyszek@in.waw.pl
Subject: Re: [PATCH RFC v3 00/10] coredump: add coredump socket
Date: Tue, 6 May 2025 09:33:58 +0200 [thread overview]
Message-ID: <20250506-umtriebe-rhabarber-161f1fcffe56@brauner> (raw)
In-Reply-To: <20250505183303.14126-1-kuniyu@amazon.com>
> > The coredump socket is located in the initial network namespace.
>
> I understand this is a reasonable decision to avoid complicated
> path management in the mount ns but keep connectivity from any
> namespace.
Yes, path lookup would not just be horrid it would also require playing
around with credentials and current->fs. The beauty in this
implementation is that its the crash dumping process itself which does
everything.
> > To bind
> > the coredump socket userspace must hold CAP_SYS_ADMIN in the initial
> > user namespace. Listening and reading can happen from whatever
> > unprivileged context is necessary to safely process coredumps.
> >
> > When a task coredumps it opens a client socket in the initial network
> > namespace and connects to the coredump socket. For now only tasks that
> > are acctually coredumping are allowed to connect to the initial coredump
> > socket.
>
> This can be controlled by BPF (cgroup sockops or LSM) if a user
> really cares about spam clients.
>
> I think how to set up coredump is userspace responsibility.
I'll reply to that in the other thread so we don't have millions of
branch points.
> > - Since unix_stream_connect() runs bpf programs during connect it's
> > possible to even redirect or multiplex coredumps to other sockets.
>
> If the socket is in a cgroup, yes, and even if not, BPF LSM can
> reject some requests.
Indeed. I've outlined that in an earlier version as well.
> > - The coredump server should mark itself as non-dumpable.
> > To capture coredumps for the coredump server itself a bpf program
> > should be run at connect to redirect it to another socket in
> > userspace. This can be useful for debugging crashing coredump servers.
> >
> > - A container coredump server in a separate network namespace can simply
> > bind to linuxafsk/coredump.socket and systemd-coredump fowards
> > coredumps to the container.
>
> I think the name should be also configurable in non-initial netns.
I don't see a good reason for this. We can always relax that later if we
have to. The fixed address keeps the coredump setup very very dumb and
simple.
prev parent reply other threads:[~2025-05-06 7:34 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-05 11:13 [PATCH RFC v3 00/10] coredump: add coredump socket Christian Brauner
2025-05-05 11:13 ` [PATCH RFC v3 01/10] coredump: massage format_corname() Christian Brauner
2025-05-05 11:13 ` [PATCH RFC v3 02/10] coredump: massage do_coredump() Christian Brauner
2025-05-05 11:13 ` [PATCH RFC v3 03/10] net: reserve prefix Christian Brauner
2025-05-05 11:13 ` [PATCH RFC v3 04/10] coredump: add coredump socket Christian Brauner
2025-05-05 12:55 ` Jann Horn
2025-05-05 13:06 ` Luca Boccassi
2025-05-05 14:46 ` Christian Brauner
2025-05-05 18:48 ` Kuniyuki Iwashima
2025-05-06 8:24 ` Christian Brauner
2025-05-05 11:13 ` [PATCH RFC v3 05/10] coredump: validate socket name as it is written Christian Brauner
2025-05-05 11:13 ` [PATCH RFC v3 06/10] coredump: show supported coredump modes Christian Brauner
2025-05-05 11:13 ` [PATCH RFC v3 07/10] pidfs, coredump: add PIDFD_INFO_COREDUMP Christian Brauner
2025-05-05 11:13 ` [PATCH RFC v3 08/10] net, pidfs, coredump: only allow coredumping tasks to connect to coredump socket Christian Brauner
2025-05-05 13:08 ` Jann Horn
2025-05-05 14:06 ` Christian Brauner
2025-05-05 18:40 ` Kuniyuki Iwashima
2025-05-05 19:10 ` Jann Horn
2025-05-05 19:35 ` Kuniyuki Iwashima
2025-05-05 19:44 ` Kuniyuki Iwashima
2025-05-05 19:55 ` Jann Horn
2025-05-05 20:41 ` Kuniyuki Iwashima
2025-05-06 7:39 ` Christian Brauner
2025-05-06 14:51 ` Jann Horn
2025-05-06 15:16 ` Christian Brauner
2025-05-06 19:28 ` Kuniyuki Iwashima
2025-05-07 11:50 ` Mickaël Salaün
2025-05-05 19:55 ` Jann Horn
2025-05-05 20:30 ` Kuniyuki Iwashima
2025-05-06 8:06 ` Christian Brauner
2025-05-06 14:37 ` Jann Horn
2025-05-06 19:18 ` Kuniyuki Iwashima
2025-05-07 11:51 ` Mickaël Salaün
2025-05-07 14:22 ` Lennart Poettering
2025-05-07 22:10 ` Paul Moore
2025-05-05 11:13 ` [PATCH RFC v3 09/10] selftests/pidfd: add PIDFD_INFO_COREDUMP infrastructure Christian Brauner
2025-05-05 11:13 ` [PATCH RFC v3 10/10] selftests/coredump: add tests for AF_UNIX coredumps Christian Brauner
2025-05-05 14:41 ` [PATCH RFC v3 00/10] coredump: add coredump socket Mickaël Salaün
2025-05-05 14:56 ` Christian Brauner
2025-05-05 15:38 ` Mickaël Salaün
2025-05-05 14:59 ` Jann Horn
2025-05-05 15:39 ` Mickaël Salaün
2025-05-05 18:33 ` Kuniyuki Iwashima
2025-05-06 7:33 ` Christian Brauner [this message]
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=20250506-umtriebe-rhabarber-161f1fcffe56@brauner \
--to=brauner@kernel.org \
--cc=alexander@mihalicyn.com \
--cc=bluca@debian.org \
--cc=daan.j.demeyer@gmail.com \
--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=me@yhndnzj.com \
--cc=netdev@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=pabeni@redhat.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