From: Tycho Andersen <tycho@tycho.pizza>
To: Florian Weimer <fweimer@redhat.com>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Christian Brauner <brauner@kernel.org>,
Oleg Nesterov <oleg@redhat.com>,
"Eric W . Biederman" <ebiederm@xmission.com>,
linux-kernel@vger.kernel.org, linux-api@vger.kernel.org,
Tycho Andersen <tandersen@netflix.com>
Subject: Re: [RFC 1/3] pidfd: allow pidfd_open() on non-thread-group leaders
Date: Wed, 6 Dec 2023 08:27:17 -0700 [thread overview]
Message-ID: <ZXCS1SMQLhSPtjdp@tycho.pizza> (raw)
In-Reply-To: <87ttp3rprd.fsf@oldenburg.str.redhat.com>
On Thu, Nov 30, 2023 at 08:43:18PM +0100, Florian Weimer wrote:
> * Mathieu Desnoyers:
>
> >>> I'd like to offer a userspace API which allows safe stashing of
> >>> unreachable file descriptors on a service thread.
>
> >> By "safe" here do you mean not accessible via pidfd_getfd()?
>
> No, unreachable by close/close_range/dup2/dup3. I expect we can do an
> intra-process transfer using /proc, but I'm hoping for something nicer.
It occurred to me that we could get the seccomp() protected-memory
functionality almost all the way via some combination of
memfd_create(MFD_ALLOW_SEALING), fcntl(F_SEAL_WRITE|F_SEAL_SEAL), and
mmap(PROT_NONE). Some other thread could come along and unmap/remap,
but perhaps with some kind of F_SEAL_NOUNMAP married to one of these
special files we could both get what we want?
I submitted a talk to FOSDEM just for grins, if anyone is planning to
attend that.
Tycho
next prev parent reply other threads:[~2023-12-06 15:27 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-30 16:39 [RFC 1/3] pidfd: allow pidfd_open() on non-thread-group leaders Tycho Andersen
2023-11-30 16:39 ` [RFC 2/3] selftests/pidfd: add non-thread-group leader tests Tycho Andersen
2023-11-30 16:39 ` [RFC 3/3] clone: allow CLONE_THREAD | CLONE_PIDFD together Tycho Andersen
2023-11-30 17:39 ` [RFC 1/3] pidfd: allow pidfd_open() on non-thread-group leaders Oleg Nesterov
2023-11-30 17:56 ` Tycho Andersen
2023-12-01 16:31 ` Tycho Andersen
2023-12-07 17:57 ` Christian Brauner
2023-12-07 21:25 ` Christian Brauner
2023-12-08 20:04 ` Tycho Andersen
2023-11-30 18:37 ` Florian Weimer
2023-11-30 18:54 ` Tycho Andersen
2023-11-30 19:00 ` Mathieu Desnoyers
2023-11-30 19:17 ` Tycho Andersen
2023-11-30 19:43 ` Florian Weimer
2023-12-06 15:27 ` Tycho Andersen [this message]
2023-12-07 22:58 ` Christian Brauner
2023-12-08 3:16 ` Jens Axboe
2023-12-08 13:15 ` Florian Weimer
2023-12-08 13:48 ` Christian Brauner
2023-12-08 13:58 ` Florian Weimer
2023-12-07 17:21 ` Christian Brauner
2023-12-07 17:52 ` Tycho Andersen
2023-12-08 17:47 ` Jan Kara
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=ZXCS1SMQLhSPtjdp@tycho.pizza \
--to=tycho@tycho.pizza \
--cc=brauner@kernel.org \
--cc=ebiederm@xmission.com \
--cc=fweimer@redhat.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=oleg@redhat.com \
--cc=tandersen@netflix.com \
/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.