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. 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. 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.  https://firstname.lastname@example.org/
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.