exec(2) exec(2)
exec: execl, execv, execle, execve, execlp, execvp - execute a file
#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);
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<b>, char *argv<b>[], char *envp<b>[]);
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.
Page 1
exec(2) exec(2)
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<b>, ..., 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-ANSIcompliant)
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.
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.
Page 2
exec(2) exec(2)
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
Page 3
exec(2) exec(2)
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)]
Page 4
exec(2) exec(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.
Page 5
exec(2) exec(2)
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)].
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), system(3S), a.out(4), proc(4), environ(5)
If exec returns to the calling process, an error has occurred; the return
value is -1 and errno is set to indicate the error.
PPPPaaaaggggeeee 6666 [ Back ]
|
