Re: exec/system wipes signal handler

1) Now both exec and system start the process ok (c prog exec)
When you do an exec() (at the OS level), all of the code in memory
for that process goes away and (if successful) is replaced by the
new program that you exec(). That includes any code being used as
a signal handler. Since the code for a signal handler has gone
away, the OS resets any signal handlers (the setting to IGNORE a
signal or use the default action will stick).

It is up to the exec()ed program to reinstate a signal handler if
it wants one.

Incorrect, Gordon. The process issuing the exec() does not go away.

I didn't say it did. I said the code in memory went away. And it
does. I'm talking about the OS call exec(), not PHP's exec(), although
PHP's exec() calls the OS exec().


The code in memory does NOT go away. It still remains, and is being
executed.

No, it's not, not in the process that calls it. And remember, I'm
talking about the OS exec(), not the PHP exec() (although the PHP
exec() calls the OS exec() ).

Rather, the system starts a new process in a new address space. Once

No, exec() does NOT start a new process (I'm talking about the OS
exec() call, not PHP's exec() call). The OS call fork() does that.

the exec() has completed, the issuing process continues on its merry way.


exec() also starts a new process. The difference is in where the
execution begin.

No, exec() does not start a new process. fork() does that. New
code gets loaded, and it starts at a different location, but it is
the same process with the same process ID, and it has the same
parent and child processes as before the exec(). The exec() call
does not return unless it fails.

EXEC(3) FreeBSD Library Functions Manual EXEC(3)

NAME
execl, execlp, execle, exect, execv, execvp, execvP -- execute a file

LIBRARY
Standard C Library (libc, -lc)

SYNOPSIS
#include <unistd.h>

extern char **environ;

int
execl(const char *path, const char *arg, ... /*, (char *)0 */);

int
execlp(const char *file, const char *arg, ... /*, (char *)0 */);

int
execle(const char *path, const char *arg, ...
/*, (char *)0, char *const envp[] */);

int
exect(const char *path, char *const argv[], char *const envp[]);

int
execv(const char *path, char *const argv[]);

int
execvp(const char *file, char *const argv[]);

int
execvP(const char *file, const char *search_path, char *const argv[]);

DESCRIPTION
The exec family of functions replaces the current process image with a
new process image. The functions described in this manual page are
front-ends for the function execve(2). (See the manual page for
execve(2) for detailed information about the replacement of the current
process.)

The initial argument for these functions is the pathname of a file which
is to be executed.

The const char *arg and subsequent ellipses in the execl(), execlp(), and
execle() functions can be thought of as arg0, arg1, ..., argn. Together
they describe a list of one or more pointers to null-terminated strings
that represent the argument list available to the executed program. The
first argument, by convention, should point to the file name associated
with the file being executed. The list of arguments must be terminated
by a NULL pointer.

The exect(), execv(), execvp(), and execvP() functions provide an array
of pointers to null-terminated strings that represent the argument list
available to the new program. The first argument, by convention, should
point to the file name associated with the file being executed. The
array of pointers must be terminated by a NULL pointer.

The execle() and exect() functions also specify the environment of the
executed process by following the NULL pointer that terminates the list
of arguments in the argument list or the pointer to the argv array with
an additional argument. This additional argument is an array of pointers
to null-terminated strings and must be terminated by a NULL pointer. The
other functions take the environment for the new process image from the
external variable environ in the current process.

Some of these functions have special semantics.

The functions execlp(), execvp(), and execvP() will duplicate the actions
of the shell in searching for an executable file if the specified file
name does not contain a slash ``/'' character. For execlp() and
execvp(), search path is the path specified in the environment by
``PATH'' variable. If this variable is not specified, the default path
is set according to the _PATH_DEFPATH definition in <paths.h>, which is
set to ``/usr/bin:/bin''. For execvP(), the search path is specified as
an argument to the function. In addition, certain errors are treated
specially.

If an error is ambiguous (for simplicity, we shall consider all errors
except ENOEXEC as being ambiguous here, although only the critical error
EACCES is really ambiguous), then these functions will act as if they
stat the file to determine whether the file exists and has suitable exe-
cute permissions. If it does, they will return immediately with the
global variable errno restored to the value set by execve(). Otherwise,
the search will be continued. If the search completes without performing
a successful execve() or terminating due to an error, these functions
will return with the global variable errno set to EACCES or ENOENT
according to whether at least one file with suitable execute permissions
was found.

If the header of a file is not recognized (the attempted execve()
returned ENOEXEC), these functions will execute the shell with the path
of the file as its first argument. (If this attempt fails, no further
searching is done.)

The function exect() executes a file with the program tracing facilities
enabled (see ptrace(2)).

RETURN VALUES
If any of the exec() functions returns, an error will have occurred. The
return value is -1, and the global variable errno will be set to indicate
the error.

FILES
/bin/sh The shell.

COMPATIBILITY
Historically, the default path for the execlp() and execvp() functions
was ``:/bin:/usr/bin''. This was changed to place the current directory
last to enhance system security.

The behavior of execlp() and execvp() when errors occur while attempting
to execute the file is not quite historic practice, and has not tradi-
tionally been documented and is not specified by the POSIX standard.

Traditionally, the functions execlp() and execvp() ignored all errors
except for the ones described above and ETXTBSY, upon which they retried
after sleeping for several seconds, and ENOMEM and E2BIG, upon which they
returned. They now return for ETXTBSY, and determine existence and exe-
cutability more carefully. In particular, EACCES for inaccessible direc-
tories in the path prefix is no longer confused with EACCES for files
with unsuitable execute permissions. In 4.4BSD, they returned upon all
errors except EACCES, ENOENT, ENOEXEC and ETXTBSY. This was inferior to
the traditional error handling, since it breaks the ignoring of errors
for path prefixes and only improves the handling of the unusual ambiguous
error EFAULT and the unusual error EIO. The behaviour was changed to
match the behaviour of sh(1).

ERRORS
The execl(), execle(), execlp(), execvp() and execvP() functions may fail
and set errno for any of the errors specified for the library functions
execve(2) and malloc(3).

The exect() and execv() functions may fail and set errno for any of the
errors specified for the library function execve(2).

SEE ALSO
sh(1), execve(2), fork(2), ktrace(2), ptrace(2), environ(7)

STANDARDS
The execl(), execv(), execle(), execlp() and execvp() functions conform
to IEEE Std 1003.1-1988 (``POSIX.1''). The execvP() function first
appeared in FreeBSD 5.2.

FreeBSD 7.1 January 24, 1994 FreeBSD 7.1


EXECVE(2) FreeBSD System Calls Manual EXECVE(2)

NAME
execve -- execute a file

LIBRARY
Standard C Library (libc, -lc)

SYNOPSIS
#include <unistd.h>

int
execve(const char *path, char *const argv[], char *const envp[]);

DESCRIPTION
The execve() system call transforms the calling process into a new
process. The new process is constructed from an ordinary file, whose
name is pointed to by path, called the new process file. This file is
either an executable object file, or a file of data for an interpreter.
An executable object file consists of an identifying header, followed by
pages of data representing the initial program (text) and initialized
data pages. Additional pages may be specified by the header to be ini-
tialized with zero data; see elf(5) and a.out(5).

An interpreter file begins with a line of the form:

#! interpreter [arg]

When an interpreter file is execve'd, the system actually execve's the
specified interpreter. If the optional arg is specified, it becomes the
first argument to the interpreter, and the name of the originally
execve'd file becomes the second argument; otherwise, the name of the
originally execve'd file becomes the first argument. The original argu-
ments are shifted over to become the subsequent arguments. The zeroth
argument is set to the specified interpreter.

The argument argv is a pointer to a null-terminated array of character
pointers to null-terminated character strings. These strings construct
the argument list to be made available to the new process. At least one
argument must be present in the array; by custom, the first element
should be the name of the executed program (for example, the last compo-
nent of path).

The argument envp is also a pointer to a null-terminated array of charac-
ter pointers to null-terminated strings. A pointer to this array is nor-
mally stored in the global variable environ. These strings pass informa-
tion to the new process that is not directly an argument to the command
(see environ(7)).

File descriptors open in the calling process image remain open in the new
process image, except for those for which the close-on-exec flag is set
(see close(2) and fcntl(2)). Descriptors that remain open are unaffected
by execve(). If any of the standard descriptors (0, 1, and/or 2) are
closed at the time execve() is called, and the process will gain privi-
lege as a result of set-id semantics, those descriptors will be re-opened
automatically. No programs, whether privileged or not, should assume
that these descriptors will remain closed across a call to execve().

Signals set to be ignored in the calling process are set to be ignored in
the new process. Signals which are set to be caught in the calling
process image are set to default action in the new process image.
Blocked signals remain blocked regardless of changes to the signal
action. The signal stack is reset to be undefined (see sigaction(2) for
more information).

If the set-user-ID mode bit of the new process image file is set (see
chmod(2)), the effective user ID of the new process image is set to the
owner ID of the new process image file. If the set-group-ID mode bit of
the new process image file is set, the effective group ID of the new
process image is set to the group ID of the new process image file. (The
effective group ID is the first element of the group list.) The real
user ID, real group ID and other group IDs of the new process image
remain the same as the calling process image. After any set-user-ID and
set-group-ID processing, the effective user ID is recorded as the saved
set-user-ID, and the effective group ID is recorded as the saved set-
group-ID. These values may be used in changing the effective IDs later
(see setuid(2)).

The set-ID bits are not honored if the respective file system has the
nosuid option enabled or if the new process file is an interpreter file.
Syscall tracing is disabled if effective IDs are changed.

The new process also inherits the following attributes from the calling
process:

process ID see getpid(2)
parent process ID see getppid(2)
process group ID see getpgrp(2)
access groups see getgroups(2)
working directory see chdir(2)
root directory see chroot(2)
control terminal see termios(4)
resource usages see getrusage(2)
interval timers see getitimer(2)
resource limits see getrlimit(2)
file mode mask see umask(2)
signal mask see sigvec(2), sigsetmask(2)

When a program is executed as a result of an execve() system call, it is
entered as follows:

main(argc, argv, envp)
int argc;
char **argv, **envp;

where argc is the number of elements in argv (the ``arg count'') and argv
points to the array of character pointers to the arguments themselves.

RETURN VALUES
As the execve() system call overlays the current process image with a new
process image the successful call has no process to return to. If
execve() does return to the calling process an error has occurred; the
return value will be -1 and the global variable errno is set to indicate
the error.

ERRORS
The execve() system call will fail and return to the calling process if:

[ENOTDIR] A component of the path prefix is not a directory.

[ENAMETOOLONG] A component of a pathname exceeded 255 characters, or
an entire path name exceeded 1023 characters.

[ENAMETOOLONG] When invoking an interpreted script, the interpreter
name exceeds MAXSHELLCMDLEN characters.

[ENOENT] The new process file does not exist.

[ELOOP] Too many symbolic links were encountered in translat-
ing the pathname.

[EACCES] Search permission is denied for a component of the
path prefix.

[EACCES] The new process file is not an ordinary file.

[EACCES] The new process file mode denies execute permission.

[ENOEXEC] The new process file has the appropriate access per-
mission, but has an invalid magic number in its
header.

[ETXTBSY] The new process file is a pure procedure (shared text)
file that is currently open for writing or reading by
some process.

[ENOMEM] The new process requires more virtual memory than is
allowed by the imposed maximum (getrlimit(2)).

[E2BIG] The number of bytes in the new process' argument list
is larger than the system-imposed limit. This limit
is specified by the sysctl(3) MIB variable
KERN_ARGMAX.

[EFAULT] The new process file is not as long as indicated by
the size values in its header.

[EFAULT] The path, argv, or envp arguments point to an illegal
address.

[EIO] An I/O error occurred while reading from the file sys-
tem.

CAVEAT
If a program is setuid to a non-super-user, but is executed when the real
uid is ``root'', then the program has some of the powers of a super-user
as well.

SEE ALSO
ktrace(1), _exit(2), fork(2), execl(3), exit(3), sysctl(3), a.out(5),
elf(5), environ(7), mount(8)

STANDARDS
The execve() system call conforms to IEEE Std 1003.1-2001 (``POSIX.1''),
with the exception of reopening descriptors 0, 1, and/or 2 in certain
circumstances. A future update of the Standard is expected to require
this behavior, and it may become the default for non-privileged processes
as well. The support for executing interpreted programs is an extension.

HISTORY
The execve() system call appeared in 4.2BSD.

FreeBSD 7.1 June 1, 1994 FreeBSD 7.1
.

Relevant Pages

  • Re: Application role to access xp_cmdshell
    ... This necessitates that your user procs be owned ... See Cross-database chaining in the SQL 2000 ... You will also need to allow non-sysadmin users to execute xp_cmdshell. ... EXEC sp_dboption 'MyDatabase', 'db chaining', true ...
    (microsoft.public.sqlserver.security)
  • Re: regex to find an stored proc name
    ... One major flaw in yours though is that is doesn't handle the return type as ... exec this a, b, c ... execute ... "Kevin Spencer" wrote: ...
    (microsoft.public.dotnet.languages.csharp)
  • Running a DTS Job from a stored procedure
    ... We now want to upgrade our SQL Servers to Windows 2003 server on a ... EXEC sp_DisplayOAErrorInfo @oPKG, @hr ... PRINT '*** Execute failed' ...
    (microsoft.public.sqlserver.dts)
  • Re: Sleep freezing
    ... >> man exec. ... > form of a standard shell pipeline where each arg becomes one ... > word of a command, and each distinct command becomes a sub- ... The word "execute" means to replace the program running in the calling ...
    (comp.unix.shell)
  • Re: how to iterate over sequence and non-sequence ?
    ... I beg to differ, you're collecting data. ... supplying pointers (that is, memory addresses like 0x15A8), how do you ... simulate a pointer is with an integer offset into an array: ... something you pass to exec can interact badly with your code? ...
    (comp.lang.python)
Loading