*nix Documentation Project
·  Home
 +   man pages
·  Linux HOWTOs
·  FreeBSD Tips
·  *niX Forums

  man pages->IRIX man pages -> standard/exec (2)              


exec(2)								       exec(2)

NAME    [Toc]    [Back]

     exec: execl, execv, execle, execve, execlp, execvp	- execute a file

SYNOPSIS    [Toc]    [Back]

     #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    [Toc]    [Back]

     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

									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

     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

									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

     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

	  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

     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

SEE ALSO    [Toc]    [Back]

     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)

DIAGNOSTICS    [Toc]    [Back]

     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 ]
 Similar pages
Name OS Title
exec_with_loader Tru64 Execute a file with a loader
rexec IRIX execute a file on a remote cell
lockf FreeBSD execute a command while holding a file lock
fileevent IRIX Execute a script when a file becomes readable or writable
hosts.equiv Tru64 A file containing the names of remote systems and users that can execute commands on the local syste...
execve Linux execute program
VkCmdManager IRIX execute commands
if IRIX Execute scripts conditionally
perlrun OpenBSD how to execute the Perl interpreter
pagsh OpenBSD execute a command without authentication
Copyright © 2004-2005 DeniX Solutions SRL
newsletter delivery service