名前

       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 マッピングを使用した NFSv2 ファイルシステムでは正常に機能しないかもしれない。なぜならば
       UID のマッピングはサーバーで 行なわれ、権利のチェックをするクライアントには見えないからである。 (NFS バー
       ジョン 3 以降ではサーバー側でチェックが実行される。) 同様の問題は 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.54 の一部 である。プロジェクトの説明とバグ報告
       に関する情報は http://www.kernel.org/doc/man-pages/ に書かれている。