[Bug libc/18433] New: posix_spawn does not return correctly upon failure to execute

[Bug libc/18433] New: posix_spawn does not return correctly upon failure to execute

[nachms+sourceware at gmail dot com]

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

            Bug ID: 18433
           Summary: posix_spawn does not return correctly upon failure to
                    execute
           Product: glibc
           Version: 2.19
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: nachms+sourceware at gmail dot com
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

posix_spawn is supposed to return a value indicating an error when it fails.
The specification for it is here:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/posix_spawn.html

>From the spec: Otherwise, no child process shall be created, the value stored
into the variable pointed to by a non-NULL pid is unspecified, and *an error
number shall be returned as the function return value* to indicate the error.

However, glibc is returning 0 (success) instead of some kind of indication of
error (such as 2 for ENOENT).

Test program:
-------------------------
#include <stdio.h>
#include <spawn.h>

int main()
{
  extern char **environ;
  char *argv[] = { "/bin/blah_blah-blah", 0 };
  pid_t pid = -1;
  int ret = posix_spawn(&pid, argv[0], 0, 0, argv, environ);
  printf("ret: %d\npid: %ld\n", ret, (long)pid);
  return(0);
}
-------------------------

"/bin/blah_blah-blah" doesn't exist, so it should not successfully spawn.

GLIBC for this program is returning:
ret: 0
pid: 17302

FreeBSD, DragonFlyBSD, NetBSD, and musl-libc all handle this correctly.
With them:
ret: 2
pid: -1 (some will put a different value here, which is allowed by the
standard)

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

[Bug libc/18433] posix_spawn does not return correctly upon failure to execute

[fweimer at redhat dot com]

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

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com
              Flags|                            |security-

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

[Bug libc/18433] posix_spawn does not return correctly upon failure to execute

[rahimi.nv at gmail dot com]

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

navid R <rahimi.nv at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rahimi.nv at gmail dot com

--- Comment #1 from navid R <rahimi.nv at gmail dot com> ---
Created attachment 8598
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8598&action=edit
Checking existence of file before forking

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

[Bug libc/18433] posix_spawn does not return correctly upon failure to execute

[pb at pbcl dot net]

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

Phil Blundell <pb at pbcl dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pb at pbcl dot net

--- Comment #2 from Phil Blundell <pb at pbcl dot net> ---
The standard does not seem to specifically require this situation to be
diagnosed in the way you suggest.  In particular, it permits;

If [an] error occurs after the calling process successfully returns from the
posix_spawn() or posix_spawnp() function, the child process may exit with exit
status 127.

and notes:

A library implementation of posix_spawn() or posix_spawnp() may not be able to
detect all possible errors before it forks the child process. POSIX.1-2008
provides for an error indication returned from a child process which could not
successfully complete the spawn operation via a special exit status which may
be detected using the status value returned by wait(), waitid(), and waitpid().

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

[Bug libc/18433] posix_spawn does not return correctly upon failure to execute

[nachms+sourceware at gmail dot com]

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

--- Comment #3 from Nach M. S. <nachms+sourceware at gmail dot com> ---
Note the return value (emphasis included):
Upon successful completion, posix_spawn() and posix_spawnp() shall return the
process ID of the child process to the parent process, in the variable pointed
to by a non-NULL pid argument, and shall return zero as the function return
value. Otherwise, no child process shall be created, the value stored into the
variable pointed to by a non-NULL pid is unspecified, ***and an error number
shall be returned as the function return value to indicate the error***. If the
pid argument is a null pointer, the process ID of the child is not returned to
the caller.

You are correct that the standard allows to exit with 127, however it
discourages that behavior and says only if the library is unable to detect all
issues is it okay to do so. I can't speak for other platforms, but it is
perfectly possible to implement this function in a library on Linux in a
feature-complete fashion.

FreeBSD, NetBSD, and musl-libc (Linux) at the library level are all capable of
detecting the errors and properly returning them without any special kernel
supports. I've also implemented this function on Linux correctly and
feature-complete with proper error handling, and it's not really a big deal to
do so.

Using any simple form of IPC, the error can be returned from the child to the
parent. The BSDs use vfork() with a variable that the child modifies and the
parent looks at. musl-libc uses a pipe. Personally, I recommend the latter
approach.

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

[Bug libc/18433] posix_spawn does not return correctly upon failure to execute

[rahimi.nv at gmail dot com]

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

--- Comment #4 from navid R <rahimi.nv at gmail dot com> ---
I developed a pipe solution but didn't get accepted . the problem raise because
glibc is supporting system without pipe2 , (we can use pipe for creating file
descriptor and  use fcntl and FD_CLOEXEC to set it proper flag , but there is
race condition between two calls . and the overall code is so messy .


#ifdef __ASSUME_PIPE2
  if (__pipe2 (pipefd, O_CLOEXEC))
    return errno; 
#else
  if (__pipe (pipefd))
    return errno; 
  if (__fcntl (pipefd[0], FD_CLOEXEC) == -1 ||
 __fcntl (pipefd[1], FD_CLOEXEC) == -1
    return errno;

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

[Bug libc/18433] posix_spawn does not return correctly upon failure to execute

[rahimi.nv at gmail dot com]

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

--- Comment #5 from navid R <rahimi.nv at gmail dot com> ---
I developed a pipe solution but didn't get accepted in mailing list . The
problem raise because glibc is supporting system without pipe2 , (we can use
pipe for creating file descriptor and  use fcntl and FD_CLOEXEC to set it
proper flag , but there is race condition between two calls . and the overall
code is so messy .


#ifdef __ASSUME_PIPE2
  if (__pipe2 (pipefd, O_CLOEXEC))
    return errno; 
#else  // FALLBACK mode in systems which does not have pipe2 call
  if (__pipe (pipefd))
    return errno; 
  /*  <==== here we have race condition ==> */
  if (__fcntl (pipefd[0], FD_CLOEXEC) == -1 ||
 __fcntl (pipefd[1], FD_CLOEXEC) == -1)
    return errno;   

With this explanation , I have change of heart , I think vfork solution would
be better .

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

[Bug libc/18433] posix_spawn does not return correctly upon failure to execute

[rahimi.nv at gmail dot com]

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

--- Comment #6 from navid R <rahimi.nv at gmail dot com> ---
By the way for further reading this the link of 
http://git.musl-libc.org/cgit/musl/tree/src/process/posix_spawn.c
musl(pipe2 approach) implementation.
and this is the link of freebsd (vfork approach) implementation :
https://github.com/freebsd/freebsd/blob/master/lib/libc/gen/posix_spawn.c

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

[Bug libc/18433] posix_spawn does not return correctly upon failure to execute

[rahimi.nv at gmail dot com]

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

navid R <rahimi.nv at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #8598|0                           |1
        is obsolete|                            |
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at sourceware dot org   |rahimi.nv at gmail dot com

--- Comment #7 from navid R <rahimi.nv at gmail dot com> ---
Created attachment 8602
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8602&action=edit
using pipe approach to check status of child

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

[Bug libc/18433] posix_spawn does not return correctly upon failure to execute

[vtjnash at gmail dot com]

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

Jameson <vtjnash at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vtjnash at gmail dot com

--- Comment #10 from Jameson <vtjnash at gmail dot com> ---
Sorry to ping an old issue, but I was noticing the documentation appears to
explicitly state the old behavior
(https://man7.org/linux/man-pages/man3/posix_spawn.3.html#ERRORS), in
contradiction to this change and the updated opengroups standard at the link in
the original issue or at https://linux.die.net/man/3/posix_spawn. Is this text
now incorrect:

ERRORS
       The posix_spawn() and posix_spawnp() functions fail only in the case
where the underlying fork(2) or vfork(2) call fails;  in these cases, these 
functions
       return an error number, which will be one of the errors described for
fork(2) or vfork(2).

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

[Bug libc/18433] posix_spawn does not return correctly upon failure to execute

[adhemerval.zanella at linaro dot org]

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

--- Comment #11 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(In reply to Jameson from comment #10)
> Sorry to ping an old issue, but I was noticing the documentation appears to
> explicitly state the old behavior
> (https://man7.org/linux/man-pages/man3/posix_spawn.3.html#ERRORS), in
> contradiction to this change and the updated opengroups standard at the link
> in the original issue or at https://linux.die.net/man/3/posix_spawn. Is this
> text now incorrect:
> 
> ERRORS
>        The posix_spawn() and posix_spawnp() functions fail only in the case
> where the underlying fork(2) or vfork(2) call fails;  in these cases, these 
> functions
>        return an error number, which will be one of the errors described for
> fork(2) or vfork(2).

You will need to check with linux-man list:
https://www.kernel.org/doc/man-pages/linux-man-ml.html

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