From: Carlos O'Donell <firstname.lastname@example.org>
To: email@example.com, Alexey Izbyshev <firstname.lastname@example.org>
Subject: Re: [musl] vfork()-based posix_spawn() has more failure modes than fork()-based one
Date: Mon, 2 May 2022 16:49:39 -0400 [thread overview]
Message-ID: <email@example.com> (raw)
On 5/2/22 15:26, Alexey Izbyshev wrote:
> I've also opened a bug about this in glibc. Maybe libcs could
> coordinate in how they handle this case.
Speaking as a glibc maintainer.
Either the kernel supports vfork or it doesn't.
A time namespace, or a seccomp filter are all the same problems,
and we should return the error to userspace.
Adding code which will only be exercised in the event that a time
namespace is in use is going to result in increased long-term
It also results in unexpected surprise behaviour when the developer
runs under a time namespace e.g. more memory usage, different code
paths taken etc.
Rather than add long-term maintenance and surprise developers my
suggestion is to fail the posix_spawn.
Users can take this up with the kernel to add support for vfork in
time namespaces, or with their sandboxing technology provider.
There might be exceptional cases where we need to add fallbacks,
but I can't see that this is one of those cases. For example clone3
to clone2 fallback is sensible.
My impression was that time namespaces as they are today were added
primarily to support CRIU process freeze and restore with different
monotonic clock offsets. If CRIU needs this to work then it would
be more effective to fix the kernel, than to fix every userspace
you need to freeze to support fork fallback.
next prev parent reply other threads:[~2022-05-02 20:49 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-02 19:26 Alexey Izbyshev
2022-05-02 20:49 ` Carlos O'Donell [this message]
2022-05-02 21:18 ` Rich Felker
2022-05-02 21:25 ` Florian Weimer
2022-05-02 21:31 ` Rich Felker
2023-02-22 22:04 ` Alexey Izbyshev
2022-05-02 21:31 ` Carlos O'Donell
2022-05-02 21:49 ` Alexey Izbyshev
2022-05-02 21:56 ` Alexey Izbyshev
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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.
Code repositories for project(s) associated with this public inbox
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).