exec(2) exec(2) NAME exec: execl, execv, execle, execve, execlp, execvp - execute a file SYNOPSIS #include <unistd.h> int execl (const char *path, const char *arg0, ..., const char *argn, (char *)0); int execv (const char *path, char *const *argv); int execle (const char *path, const char *arg0, ..., const char *argn, (char *)0, const char *envp[]); int execve (const char *path, char *const *argv, char *const *envp); int execlp (const char *file, const char *arg0, ..., const char *argn, (char *)0); int execvp (const char *file, char *const *argv); DESCRIPTION exec in all its forms overlays a new process image on an old process. The new process image is constructed from an ordinary, executable file. This file is either an executable object file, or a file of data for an interpreter. There can be no return from a successful exec because the calling process image is overlaid by the new process image. An interpreter file begins with a line of the form #! pathname [arg] where pathname is the path of the interpreter, and arg is an optional argument. This line may be up to 256 characters long. arg includes all characters from the first non-space character after pathname up to, but not including, the newline. Any tabs in arg are converted to spaces. When an interpreter file is exec'd, the system execs the specified interpreter. The pathname specified in the interpreter file is passed as arg0 to the interpreter. If arg was specified in the interpreter file, it is passed as arg1 to the interpreter. The remaining arguments to the interpreter are arg0 through argn of the originally exec'd file. When a C program is executed, it is called as follows: int main (int argc, char *argv[], char *envp[]); where argc is the argument count, argv is an array of character pointers to the arguments themselves, and envp is an array of character pointers to the environment strings. As indicated, argc is at least one, and the first member of the array points to a string containing the name of the file. path points to a path name that identifies the new process file. file, which is only used with execlp and execvp, points to the new process file. If file does not contain a slash character, the path prefix for this file is obtained by a search of the directories passed in the PATH environment variable [see environ(5)]. The environment is supplied typically by the shell [see sh(1)]. If the new process file is not an executable object file, execlp and execvp use the contents of that file as standard input to sh(1). However, if the new process file is setuid or setgid, the input is passed via /dev/fd/N (see below for details). The arguments arg0, ..., argn point to null-terminated character strings. These strings constitute the argument list available to the new process image. Minimally, arg0 must be present. It will become the name of the process, as displayed by the ps command. Conventionally, arg0 points to a string that is the same as path (or the last component of path). The list of argument strings is terminated by a (char *)0 argument. argv is an array of character pointers to null-terminated strings. These strings constitute the argument list available to the new process image. By convention, argv must have at least one member, and it should point to a string that is the same as path (or its last component). argv is terminated by a null pointer. envp is an array of character pointers to null-terminated strings. These strings constitute the environment for the new process image. envp is terminated by a null pointer. For execl, execv, execvp, and execlp, the C run-time start-off routine places a pointer to the environment of the calling process in the global object extern char **_environ, and it is used to pass the environment of the calling process to the new process. Unless compilation is done in a pure ANSI environment (see cc(1)), the global variable _environ is aliased to the well-known (but non-ANSI- compliant) name environ. File descriptors open in the calling process remain open in the new process, except for those whose close-on-exec flag is set; [see fcntl(2)]. For those file descriptors that remain open, the file pointer is unchanged. Under certain circumstances, the file descriptors associated with stdio may be automatically opened by libc. See stdio(3s) for more information. Signals that are being caught by the calling process are set to the default disposition in the new process image [see signal(2)]. Otherwise, the new process image inherits the signal dispositions of the calling process. For signals set by sigset(2), sigaction(2), or sigvec(3B), exec will ensure that the new process has the same system signal action for each signal type whose action is SIG_DFL, SIG_IGN, or SIG_HOLD as the calling process. However, if the action is to catch the signal, then the action will be reset to SIG_DFL. All signal masks associated with handlers are cleared. If the file resides on a file system which has been mounted with the nosuid option [see fstab(4)] then the effective user ID, the effective group ID and the current capability set [see capabilities(4)] will remain unchanged. Otherwise, if the set-user-ID (SUID) mode bit of the new process file is set [see chmod(2)], exec sets the effective user ID of the new process to the owner ID of the new process file. Similarly, if the set-group-ID (SGID) mode bit of the new process file is set, the effective group ID of the new process is set to the group ID of the new process file. And finally, if attributes for the file are accessible [see attr_get(2)] and the SGI_CAP_FILE attribute is attached to the file (SCAP), then this is used to change the process' capabilities (see capabilities(4)). The real user ID, real group ID, and supplementary group IDs of the new process remain the same as those of the calling process. The saved user and group IDs of the new process are set to the effective user and group IDs of the calling process. If the effective user-ID is 0, the set-user-ID (SUID) and set-group-ID (SGID) file mode bits and any capabilities attached to the file (SCAP) will be honored when the process is being controlled by ptrace. When an image with set-user-ID (SUID), set-group-ID (SGID) or attached capabilities (SCAP) is executed it is dangerous from a security standpoint to respect certain environment variables which may allow arbitrary code to be linked into the new process image. Examples include rld's _RLD*_LIST and LD_LIBRARY*_PATH environment variables and the Image Format Library's IFL_DATABASE environment variable (see rld(1) and ifl(1)), and catopen's NLSPATH environment variable, which allows user control of message formatting (see catopen(3C)). As a result, these environment variables are ignored when such an image is executed. The semantics for determining when it is dangerous to respect such environment variables are: the real and effective user IDs are different, or the real and effective group IDs are different or if a process has any effective or permitted capabilities. Allowing such environment variables to be used in these circumstances is dangerous because an unprivileged user may execute an image which has privileges associated with it. Allowing the user to specify arbitrary code to be linked into the new privileged process image would give the user the ability to circumvent the security policies instituted by the system administrator. For instance, if an arbitrary dynamic linked object (DSO) were linked in which provided a resolution for the symbol strcpy, the priviledge process could call the strcpy() function thinking that it was making a ``safe'' call to a standard library routine. Because of the above security restrictions, a dynamic executable with attached permissions (SUID, SGID, and/or SCAP) will not be able to use the LD_LIBRARY*_PATH environment variables to find dynamic shared objects (DSO's) in non-standard library locations. Instead, the executable must either explicitly specify the locations of the DSO's it wants to load in its dlopen(3) calls or must have an rpath embedded within it which specifies the non-standard library locations that need to be searched for its DSO's (see the documentation for the -rpath option in ld(1)). Set-user-ID (SUID), set-group-ID (SGID) interpreter files and those with attached capabilities (SCAP) are handled in a special manner. If execution of an interpreter file will change either the user orgroup ID or the file has attached capabilities, IRIX will open the interpreter file for reading (subject to the read permissions of the interpreter file and the user and group ID of the new process). A pathname corresponding to the interpreter file descriptor will be substituted for the pathname of the interpreter file in the argument list passed to the intepreter. This pathname will be of the form /dev/fd/N where N is the number of the interpreter file descriptor. The shared memory segments attached to the calling process will not be attached to the new process [see shmop(2)]. If the process is a member of a share group, it is removed from that share group [see sproc(2)]. Profiling is disabled for the new process; see profil(2). Ability to access graphics is disabled. The new process also inherits the following attributes from the calling process: nice value [see nice(2)] process ID parent process ID process group ID real user and group IDs supplementary groups IDs [see getgroups(2)] semadj values [see semop(2)] session ID [see exit(2) and signal(2)] trace flag [see ptrace(2) request 0] time left until an alarm clock signal [see alarm(2)] interval timers [see getitimer(2)] current working directory root directory file mode creation mask [see umask(2)] file size limit [see ulimit(2)] resource limits [see getrlimit(2)] utime, stime, cutime, and cstime [see times(2)] file-locks [see fcntl(2) and lockf(3C)] controlling terminal process signal mask [see sigprocmask(2)] pending signals [see sigpending(2)] Upon successful completion, exec marks for update the st_atime field of the file. Should the exec succeed, the process image file is considered to have been open()-ed. The corresponding close() is considered to occur at a time after this open, but before process termination or successful completion of a subsequent call to exec. exec will fail and return to the calling process if one or more of the following are true: EACCES Search permission is denied for a directory listed in the new process file's path prefix. EACCES The new process file is not an ordinary file. EACCES Execute permission on the new process file is denied. E2BIG The number of bytes in the new process's argument list is greater than the system-imposed limit {ARG_MAX} [see sysconf(2), intro(2), and limits.h]. The argument list limit is the sum of the size of the argument list plus the size of the environment's exported shell variables. E2BIG The number of bytes in the first line of an interpreter file is greater than 256 bytes. EAGAIN Not enough memory. EFAULT An argument points to an illegal address. ELIBACC Required shared library does not have execute permission. ELIBEXEC Trying to exec(2) a shared library directly. ELIBMAX The required number of shared libraries exceeds the system imposed maximum {SHLIB_MAX} [see intro(2)]. ELOOP Too many symbolic links were encountered in translating path or file. ENAMETOOLONG The length of the file or path argument exceeds {PATH_MAX}, or the length of a file or path component exceeds {NAME_MAX} while _POSIX_NO_TRUNC is in effect. ENOENT One or more components of the new process path name of the file do not exist or is a null pathname. ENOTDIR A component of the new process path of the file prefix is not a directory. ENOEXEC The exec is not an execlp or execvp, and the new process file has the appropriate access permission but an invalid magic number in its header. ENOEXEC The executable object file has badly formed header information. ENOEXEC The requested virtual addresses are not available. ENOMEM The new process requires more virtual space than is allowed either by the system-imposed maximum or the process imposed maximum {PROCSIZE_MAX} [see getrlimit(2) and intro(2)]. EPERM A non-superuser attempts to execute a setuid or setgid shell script with a uid or gid which is different than the user's effective uid/gid, and the configured value for nosuidshells is non-zero (the default) [see intro(2) and lboot(1M)]. SEE ALSO ps(1), sh(1), lboot(1M), intro(2), alarm(2), exit(2), fcntl(2), fork(2), getgroups(2), getrlimit(2), nice(2), pcreate(2), ptrace(2), semop(2), sigaction(2), signal(2), sigpending(2), sigprocmask(2), sigset(2), sproc(2), sysconf(2), times(2), ulimit(2), umask(2), lockf(3C), signal(3B), sigvec(3B), stdio(3S), system(3S), a.out(4), proc(4), environ(5) DIAGNOSTICS If exec returns to the calling process, an error has occurred; the return value is -1 and errno is set to indicate the error. Page 6