名前

access -ファイルに対する実ユーザーでのアクセス権をチェックする

書式

#include <unistd.h>
int access(const char * pathname , int mode );

説明

access() は、呼び出し元プロセスがファイル pathname にアクセスできるかどうかをチェックする。 pathname がシンボリック・リンクの場合、シンボリック・リンクは展開される。 mode はチェックを行うアクセス権を指定するもので、その値は F_OK、もしくは R_OK, W_OK, X_OK の 1個以上のビット単位の論理和から構成されるマスクである。 F_OK はファイルが存在するかどうかのみを検査する。 R_OK, W_OK, X_OK は、ファイルが存在して、それぞれ読み込み、書き込み、実行の許可があるかを検査する。 チェックは、実際に操作が行われる際に使用される実効 (effective) ID でなく、呼び出し元プロセスの 実 (real) UID と 実 (real) GID を使って行われる。これにより、set-user-ID プログラムで、プログラムを起動するユーザの権限を簡単に決定することができる。 呼び出し元プロセスが特権プロセス (つまり、プロセスの実 UID が 0) の場合、通常のファイルに対する X_OK のチェックは、そのファイルの所有者、グループ、他人のいずれかの実行許可が有効になっていれば成功する。

返り値

成功した場合 (要求した全てについて許可が得られたか、 mode が F_OK でファイルが存在した場合)、ゼロが返される。エラーの場合 ( mode の少なくとも一つのビットで要求した許可がなかった場合、 mode が F_OK でファイルが存在しなかった場合、他のエラーが起こった場合)、-1 が返され、 errno が適切に設定される。

エラー

access() は以下の場合に失敗する。

EACCES

要求されたアクセスはそのファイル自身に拒否されたか pathname へ至るまでディレクトリのいずれかに対する検索許可 (search permission) が得られなかった。 ( path_resolution(7) も参照のこと)

ELOOP

pathname を解決するときに、解決すべきシンボリックリンクが多すぎた。

ENAMETOOLONG

pathname が長過ぎる。

ENOENT

pathname を構成するパスのいずれかが、存在しないか、参照先のない (dangling) シンボリックリンクになっている。

ENOTDIR

pathname のディレクトリ部分が実際にはディレクトリでない。

EROFS

読み込み専用 (read-only) のファイル・システムに対して書き込み許可を要求した。

access() は以下の理由により失敗することがある。

EFAULT

pathname がアクセス可能なアドレス空間の外を指している。

EINVAL

mode に不正な値が指定された。

EIO

I/O エラーが発生した。

ENOMEM

カーネルに十分なメモリがない。

ETXTBSY

実行中のファイルに対して書き込みを要求した。

準拠

SVr4, 4.3BSD, POSIX.1-2001.

注意

警告: あるユーザが、例えば open(2) によるアクセスが可能かどうかを、 (実際に行う前に) access() を使ってチェックするのは、セキュリティホールの原因になる。なぜならチェックをしてから実際にファイルのオープン操作をする間の短い間隔を悪用できるからである。 この理由があるので、この システムコールを使うのは避けるべきである。 (ここで説明した例の場合には、より安全な方法としては、そのプロセスの実効ユーザ ID を実ユーザ ID に一時的に切り替えてから open(2) を呼び出す方法がある。)

access() は常にシンボリックリンクの展開を行う。シンボリックリンクのアクセス許可を確認する必要がある場合は、 AT_SYMLINK_NOFOLLOW フラグ付きで faccessat(2) を使うこと。

mode で指定されたアクセス種別のいずれか一つでも拒否されると、たとえ mode で指定された他のアクセス種別が許可されたとしても、 access() はエラーを返す。

POSIX.1-2001 では、呼び出し元プロセスが適切な特権を持っている場合 (つまり、スーパーユーザの場合)、たとえファイルの実行許可ビットが全くセットされていなくても X_OK のチェックとして成功を返す実装が認められている。 Linux はこのようにはなっていない。

pathname のプレフィックスを構成するディレクトリの全てに対して検索アクセス (すなわち、実行アクセス) が許可された場合にのみ、ファイルはアクセス可能となる。いずれかのディレクトリがアクセス不可の場合、ファイル自身のアクセス許可に関わらず、 access() は失敗する。

アクセス・ビットのみがチェックされ、ファイルの種類や内容はチェックされない。従って、ディレクトリが書き込み可能となった場合は、ディレクトリにファイルを作成することが可能なことを意味するのであり、ディレクトリにファイルとして書き込むことができるわけではない。同様に DOS のファイルは「実行可能」と判断されるが、 execve(2) コールは失敗するだろう。

access() は、 UID マッピングを使用した NFS ファイルシステムでは正常に機能しないかもしれない。なぜならば UID のマッピングはサーバーで行なわれ、権利のチェックをするクライアントには見えないからである。同様の問題は FUSE マウントでも起こり得る。

バグ

バージョン 2.4 (とそれ以前) のカーネルには、スーパーユーザでの X_OK のチェックの扱いに奇妙な点がある。ディレクトリ以外のファイルで (ユーザ、グループ、他人の) 全てのカテゴリについて実行許可がない場合、 access() のチェックで-1 が返るのは mode に X_OK だけが指定されたときだけであり mode に R_OK や W_OK が一緒に指定された場合には access() は 0 を返す。 (バージョン 2.6.3 以前の) 初期の 2.6 系のカーネルも 2.4 系のカーネルと同様の動作をする。 2.6.20 より前のカーネルでは、ファイルが存在するファイルシステムを mount(2) する際に指定された MS_NOEXEC フラグの効果を、 access() は無視していた。カーネル 2.6.20 以降では、 access() はこのフラグを考慮するようになっている。

関連項目

chmod(2), chown(2), faccessat(2), open(2), setgid(2), setuid(2), stat(2), eauidaccess(3), credentials(7), path_resolution(7)

この文書について

この man ページは Linux man-pages プロジェクトのリリース 3.51 の一部である。プロジェクトの説明とバグ報告に関する情報は http://www.kernel.org/doc/man-pages/ に書かれている。