fexecve(3)

NAME

   fexecve - execute program specified via file descriptor

SYNOPSIS

   #include <unistd.h>

   int fexecve(int fd, char *const argv[], char *const envp[]);

   Feature Test Macro Requirements for glibc (see feature_test_macros(7)):

   fexecve():
       Since glibc 2.10:
           _POSIX_C_SOURCE >= 200809L
       Before glibc 2.10:
           _GNU_SOURCE

DESCRIPTION

   fexecve() performs the same task as execve(2), with the difference that
   the file to be executed is specified via a file descriptor, fd,  rather
   than  via a pathname.  The file descriptor fd must be opened read-only,
   and the caller must have permission to execute the file that it  refers
   to.

RETURN VALUE

   A  successful  call to fexecve() never returns.  On error, the function
   does return, with a result value of -1, and errno is set appropriately.

ERRORS

   Errors are as for execve(2), with the following additions:

   EINVAL fd is not a valid file descriptor, or argv is NULL, or  envp  is
          NULL.

   ENOSYS The /proc filesystem could not be accessed.

VERSIONS

   fexecve() is implemented since glibc 2.3.2.

ATTRIBUTES

   For   an   explanation   of   the  terms  used  in  this  section,  see
   attributes(7).

   
   Interface  Attribute      Value   
   
   fexecve()  Thread safety  MT-Safe 
   

CONFORMING TO

   POSIX.1-2008.  This function is not specified in POSIX.1-2001,  and  is
   not   widely   available   on   other  systems.   It  is  specified  in
   POSIX.1-2008.

NOTES

   On Linux, fexecve() is implemented using  the  proc(5)  filesystem,  so
   /proc needs to be mounted and available at the time of the call.

   The  idea  behind fexecve() is to allow the caller to verify (checksum)
   the contents of an executable before executing it.  Simply opening  the
   file,  checksumming the contents, and then doing an execve(2) would not
   suffice, since, between the two steps, the  filename,  or  a  directory
   prefix  of  the  pathname,  could have been exchanged (by, for example,
   modifying the target of a symbolic link).  fexecve() does not  mitigate
   the  problem  that  the contents of a file could be changed between the
   checksumming and the call to fexecve(); for that, the  solution  is  to
   ensure  that the permissions on the file prevent it from being modified
   by malicious users.

   The natural idiom when using fexecve() is to set the close-on-exec flag
   on fd, so that the file descriptor does not leak through to the program
   that is executed.  This approach is natural for two reasons.  First, it
   prevents  file descriptors being consumed unnecessarily.  (The executed
   program normally has no need of a file descriptor that  refers  to  the
   program  itself.)   Second, if fexecve() is used recursively, employing
   the close-on-exec flag prevents the  file  descriptor  exhaustion  that
   would  result from the fact that each step in the recursion would cause
   one more file descriptor to be passed to the  new  program.   (But  see
   BUGS.)

BUGS

   If  fd  refers  to  a  script (i.e., it is an executable text file that
   names a script interpreter with a  first  line  that  begins  with  the
   characters  #!)   and  the close-on-exec flag has been set for fd, then
   fexecve() fails with the error ENOENT.  This error occurs  because,  by
   the time the script interpreter is executed, fd has already been closed
   because of the close-on-exec flag.  Thus, the close-on-exec flag  can't
   be  set  on  fd  if  it  refers  to  a  script, leading to the problems
   described in NOTES.

SEE ALSO

   execve(2), execveat(2)

COLOPHON

   This page is part of release 4.09 of the Linux  man-pages  project.   A
   description  of  the project, information about reporting bugs, and the
   latest    version    of    this    page,    can     be     found     at
   https://www.kernel.org/doc/man-pages/.

---

Free and Open Source Software