int execve(const char *pathname, char *const argv[],
char *const envp[]);
pathname は、バイナリ実行形式か、 以下の形式の行で始まるスクリプトでなければならない。
#!interpreter [optional-arg]
後者の詳細は、後ろの「インタープリタースクリプト」の節を参照のこと。
argv is an array of pointers to strings passed to the new program as its command-line arguments. By convention, the first of these strings (i.e., argv[0]) should contain the filename associated with the file being executed. The argv array must be terminated by a NULL pointer. (Thus, in the new program, argv[argc] will be NULL.)
envp is an array of pointers to strings, conventionally of the form key=value, which are passed as the environment of the new program. The envp array must be terminated by a NULL pointer.
The argument vector and environment can be accessed by the new program's main function, when it is defined as:
int main(int argc, char *argv[], char *envp[])
Note, however, that the use of a third argument to the main function is not specified in POSIX.1; according to POSIX.1, the environment should be accessed via the external variable environ(7).
execve() does not return on success, and the text, initialized data, uninitialized data (bss), and stack of the calling process are overwritten according to the contents of the newly loaded program.
元のプログラムが ptrace されている場合、 execve() が成功した後に そのプログラムに SIGTRAP シグナルが送られる。
pathname で参照されるプログラムファイルに set-user-ID ビットが設定されている場合、呼び出したプロセスの実効 (effective) ユーザー ID は プログラムファイルの所有者 (owner) に変更される。 同様に、プログラムファイルに set-group-ID ビットが設定されていた場合、 呼び出したプロセスの有効グループ ID は プログラムファイルのグループに変更される。
The aforementioned transformations of the effective IDs are not performed (i.e., the set-user-ID and set-group-ID bits are ignored) if any of the following is true:
The capabilities of the program file (see capabilities(7)) are also ignored if any of the above are true.
プロセスの実効ユーザー ID は保存 (saved) set-user-ID にコピーされる。 同様に、実効グループ ID は保存 set-group-ID にコピーされる。 このコピーは、set-user-ID / set-group-ID モードビットにより発生する 実効 ID の変更後に行われる。
The process's real UID and real GID, as well its supplementary group IDs, are unchanged by a call to execve().
実行ファイルが動的リンクされた a.out 実行形式で、共有ライブラリの スタブを含むものだった場合、実行の開始時に Linux の ダイナミックリンカー ld.so(8) が呼び出され、必要な共有オブジェクトをメモリーに読み込んでリンクを行う。
実行ファイルがダイナミックリンクされた ELF 実行形式だった場合、 PT_INTERP セグメントに指定されたインタープリターが必要な 共有オブジェクト (shared library) を読み込むのに使用される。 通常、インタープリターは glibc をリンクしたバイナリでは /lib/ld-linux.so.2 である。 (ld-linux.so(8) を参照)
上記のリストのプロセス属性はいずれも POSIX.1 で規定されている。 以下に示す Linux 固有のプロセス属性も execve() の前後で保持されない。
以下の点についても注意すること:
#!interpreter [optional-arg]
The interpreter must be a valid pathname for an executable file.
execve() の pathname 引数がインタープリタースクリプトを指定している場合、 interpreter は以下の引数で起動される。
interpreter [optional-arg] pathname arg...
where pathname is the absolute pathname of the file specified as the first argument of execve(), and arg... is the series of words pointed to by the argv argument of execve(), starting at argv[1]. Note that there is no way to get the argv[0] that was passed to the execve() call.
移植性を持たすには、 optional-arg は空か 1ワードだけにすべきである (つまり、ホワイトスペースを含めるべきではない)。 下記の「注意」の節を参照。
Since Linux 2.6.28, the kernel permits the interpreter of a script to itself be a script. This permission is recursive, up to a limit of four recursions, so that the interpreter may be a script which is interpreted by a script, and so on.
カーネル 2.6.23 より前の Linux では、環境変数と引数の文字列群を 格納するのに使用されるメモリーは 32 ページに制限されていた (32 ページというのはカーネル定数 MAX_ARG_PAGES で定義される)。したがって、 ページサイズが 4 kB のアーキテクチャーでは、 最大サイズは 128 kB ということになる。
On kernel 2.6.23 and later, most architectures support a size limit derived from the soft RLIMIT_STACK resource limit (see getrlimit(2)) that is in force at the time of the execve() call. (Architectures with no memory management unit are excepted: they maintain the limit that was in effect before kernel 2.6.23.) This change allows programs to have a much larger argument and/or environment list. For these architectures, the total size is limited to 1/4 of the allowed stack size. (Imposing the 1/4-limit ensures that the new program always has some stack space.) Additionally, the total size is limited to 3/4 of the value of the kernel constant _STK_LIM (8 Mibibytes). Since Linux 2.6.25, the kernel also places a floor of 32 pages on this size limit, so that, even when RLIMIT_STACK is set very low, applications are guaranteed to have at least as much argument and environment space as was provided by Linux 2.6.23 and earlier. (This guarantee was not provided in Linux 2.6.23 and 2.6.24.) Additionally, the limit per string is 32 pages (the kernel constant MAX_ARG_STRLEN), and the maximum number of strings is 0x7FFFFFFF.
set-user-id プロセスと set-group-ID プロセスは ptrace(2) できない。
ファイルシステムを nosuid でマウントした場合に set-user-ID/set-group-ID の実行ファイルを どの様に扱うかは、Linux カーネルのバージョンによって異なる: あるバージョンでは、すでに必要な権限を持っている場合を除いて、 その実行を拒否する (そして EPERM を返す)。別のあるバージョンでは set-user-ID/set-group-ID ビットのみを無視し exec() は成功する。
On Linux, argv and envp can be specified as NULL. In both cases, this has the same effect as specifying the argument as a pointer to a list containing a single null pointer. Do not take advantage of this nonstandard and nonportable misfeature! On many other UNIX systems, specifying argv as NULL will result in an error (EFAULT). Some other UNIX systems treat the envp==NULL case the same as Linux.
POSIX.1 は、 sysconf(3) が返す値はプロセスの生存中は変化しないべきだとしている。 しかしながら、Linux 2.6.23 以降では、リソース上限 RLIMIT_STACK が変化した場合、 コマンドライン引数と環境変数を保持するための空間に対する上限が 変化したことを反映して、 _SC_ARG_MAX が返す値も変化する。
execve() が失敗するほとんどの場合、 制御は元の実行可能イメージに戻り、 execve() の呼び出し元がエラーを処理することができる。 しかしながら、 (リソース枯渇が原因となった場合など、まれに) 呼び出し元に制御が戻る時点を過ぎてからエラーが発生する場合がある。 元の実行可能イメージはすでに破棄されているが、 新しいイメージが完全には構築されていないという状況である。 このような場合、カーネルはそのプロセスをシグナル SIGSEGV (Linux 3.17 までは SIGKILL) で停止 (kill) する。
インタープリタースクリプトの optional-arg 引数の解釈方法は実装により異なる。 Linux では、インタープリター名 interpreter に続く文字列全体がインタープリターに 1個の引数として渡される。 しかし、動作が異なるシステムもある。 あるシステムでは、 optional-arg のうち最初のホワイトスペースまでが 引数として渡される。 また、別のシステムでは インタープリタースクリプトは複数の引数を持つことができ、 optional-arg 内のホワイトスペースが引数の区切りとなる。
Linux (like most other modern UNIX systems) ignores the set-user-ID and set-group-ID bits on scripts.
直前の setuid(2), setreuid(2), setresuid(2) の呼び出しで、 そのプロセスの実ユーザー ID が変更され、 その変更によりそのプロセスが RLIMIT_NPROC リソース上限を超過してしまった場合 (すなわち、新しい実ユーザー ID に属するプロセス数が RLIMIT_NPROC リソース上限を超過した場合) に、 EAGAIN エラーが発生する。 Linux 2.6.0 以上 3.0 以下では、これにより set*uid() の呼び出しが失敗していた。 (Linux 2.6 より前では、このリソース上限はユーザー ID を変更したプロセスには適用されていなかった。)
Linux 3.1 以降では、上で説明したシナリオでは set*uid() の呼び出しは失敗しない。 なぜなら、 返されたステータスの確認を行わず「呼び出し元が特権を持っている場合には」呼び出しは必ず成功するとみなしているバグがあるアプリケーションでは、セキュリティホールにつながることが非常によくあるからだ。 その代わり、 set*uid() の呼び出しによる実 UID の変更は成功するが、 カーネルは PF_NPROC_EXCEEDED という名前の内部フラグをセットする。 このフラグは RLIMIT_NPROC リソース上限が超過したことを示す。 PF_NPROC_EXCEEDED フラグがセットされていて、その後で execve() が呼ばれた際にリソース上限がまだ超過していれば、 その execve() の呼び出しは EAGAIN エラーで失敗する。 このカーネルのロジックにより、 特権デーモンでよく行われる処理フロー、 すなわち fork(2) + set*uid() + execve() に対して、前と変わらず RLIMIT_NPROC リソース上限を適用できることが保証される。
(set*uid() と execve() の呼び出しの間に、この実 UID に属する他のプロセスが終了して) 次に execve() が呼び出された際にこのリソース上限が超過してなければ、 execve() の呼び出しは成功し、カーネルは PF_NPROC_EXCEEDED プロセスフラグをクリアする。 同じプロセスによって fork(2) の呼び出しが後で行われた場合にも、このフラグはクリアされる。
/* myecho.c */
#include <stdio.h> #include <stdlib.h>
int
main(int argc, char *argv[])
{
for (int j = 0; j < argc; j++)
printf("argv[%d]: %s\n", j, argv[j]);
exit(EXIT_SUCCESS);
}
以下のプログラムは、コマンドライン引数で指定した名前のプログラムを 実行するのに使う。
/* execve.c */
#include <stdio.h> #include <stdlib.h> #include <unistd.h>
int
main(int argc, char *argv[])
{
char *newargv[] = { NULL, "hello", "world", NULL };
char *newenviron[] = { NULL };
if (argc != 2) {
fprintf(stderr, "Usage: %s <file-to-exec>\n", argv[0]);
exit(EXIT_FAILURE);
}
newargv[0] = argv[1];
execve(argv[1], newargv, newenviron);
perror("execve"); /* execve() returns only on error */
exit(EXIT_FAILURE);
}
二つ目のプログラムを使って一つ目のプログラムを実行するには 以下のようにする。
$ cc myecho.c -o myecho $ cc execve.c -o execve $ ./execve ./myecho argv[0]: ./myecho argv[1]: hello argv[2]: world
さらに、これらのプログラムを使って、スクリプトインタープリターの例を示す。 このために、「インタープリター」として先ほど作成したプログラム myecho を使うスクリプトを作成する。
$ cat > script #!./myecho script-arg ^D $ chmod +x script
作成しておいたプログラムを使ってスクリプトを実行する。
$ ./execve ./script argv[0]: ./myecho argv[1]: script-arg argv[2]: ./script argv[3]: hello argv[4]: world