[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 2 May 2022 16:49:39 -0400
From: Carlos O'Donell <carlos@...hat.com>
To: musl@...ts.openwall.com, Alexey Izbyshev <izbyshev@...ras.ru>
Subject: Re: vfork()-based posix_spawn() has more failure modes than
fork()-based one
On 5/2/22 15:26, Alexey Izbyshev wrote:
> I've also opened a bug about this in glibc[2]. 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
maintenance costs.
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[1]. 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.
--
Cheers,
Carlos.
[1] https://lore.kernel.org/lkml/158016896588.31887.14143226032971732742.tglx@nanos.tec.linutronix.de/
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
