[Bug libc/29115] New: vfork()-based posix_spawn() has more failure modes than fork()-based one

["izbyshev at ispras dot ru" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=29115

            Bug ID: 29115
           Summary: vfork()-based posix_spawn() has more failure modes
                    than fork()-based one
           Product: glibc
           Version: 2.35
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: izbyshev at ispras dot ru
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

Modern vfork()-based posix_spawn() can be used as an efficient alternative to
fork()/exec() to avoid performance and overcommit issues. A common expectation
is that whenever posix_spawn() feature set is sufficient for application needs
of tweaking the child attributes, it can be used instead of fork()/exec().

However, it turns out that vfork() can have failure modes than fork() doesn't
have. One such case is due to Linux not allowing processes in different time
namespaces to share address space.

$ cat test.c
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <spawn.h>
#include <unistd.h>

int main(int argc, char *argv[], char *envp[]) {
  if (getenv("TEST_FORK")) {
    pid_t pid = fork();
    if (pid < 0) {
        perror("fork");
        return 127;
    }
    if (pid == 0) {
        execve(argv[1], argv + 1, envp);
        perror("execve");
        return 127;
    }
  } else {
      int err = posix_spawn(0, argv[1], 0, 0, argv + 1, envp);
      if (err) {
        printf("posix_spawn: %s\n", strerror(err));
        return 127;
      }
  }
  printf("OK\n");
  return 0;
}

$ gcc test.c

$ unshare -UrT ./a.out /bin/true
posix_spawn: Operation not permitted

(The actual clone() error is EINVAL, but it's reported incorrectly due to bug
29109).

$ TEST_FORK=1 unshare -UrT ./a.out /bin/true
OK

I'm not aware of other failure modes, but more might appear in the future.

Does this qualify as a glibc bug? Should glibc's posix_spawn() implementation,
for example, retry with fork() on vfork() failure (which would require a
redesign of error reporting from the child process because it currently relies
on address space sharing)?

Or do applications are expected to deal with that somehow? In this case, what
is the recommended way to do that, given that it's not possible to reliably
detect "retriable" posix_spawn() failures?

-- 
You are receiving this mail because:
You are on the CC list for the bug.