From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <sourceware-bugzilla@sourceware.org>
Received: by sourceware.org (Postfix, from userid 48)
 id 918163858406; Mon,  2 May 2022 12:08:51 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 918163858406
From: "izbyshev at ispras dot ru" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/29115] New: vfork()-based posix_spawn() has more failure
 modes than fork()-based one
Date: Mon, 02 May 2022 12:08:51 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: libc
X-Bugzilla-Version: 2.35
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: izbyshev at ispras dot ru
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status
 bug_severity priority component assigned_to reporter cc target_milestone
Message-ID: <bug-29115-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: glibc-bugs@sourceware.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Glibc-bugs mailing list <glibc-bugs.sourceware.org>
List-Unsubscribe: <https://sourceware.org/mailman/options/glibc-bugs>,
 <mailto:glibc-bugs-request@sourceware.org?subject=unsubscribe>
List-Archive: <https://sourceware.org/pipermail/glibc-bugs/>
List-Help: <mailto:glibc-bugs-request@sourceware.org?subject=help>
List-Subscribe: <https://sourceware.org/mailman/listinfo/glibc-bugs>,
 <mailto:glibc-bugs-request@sourceware.org?subject=subscribe>
X-List-Received-Date: Mon, 02 May 2022 12:08:51 -0000

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

            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 expectat=
ion
is that whenever posix_spawn() feature set is sufficient for application ne=
eds
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 =3D fork();
    if (pid < 0) {
        perror("fork");
        return 127;
    }
    if (pid =3D=3D 0) {
        execve(argv[1], argv + 1, envp);
        perror("execve");
        return 127;
    }
  } else {
      int err =3D 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 b=
ug
29109).

$ TEST_FORK=3D1 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() implementati=
on,
for example, retry with fork() on vfork() failure (which would require a
redesign of error reporting from the child process because it currently rel=
ies
on address space sharing)?

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

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