ACCESS(2) | Linux Programmer's Manual | ACCESS(2) |
名前
access -ファイルに対する実ユーザーでのアクセス権をチェックする書式
#include <unistd.h>
int access(const char * pathname , int mode );
説明
access() は、呼び出し元プロセスがファイル pathname にアクセスできるかどうかをチェックする。 pathname がシンボリック・リンクの場合、シンボリック・リンクは展開される。返り値
成功した場合 (要求した全てについて許可が得られたか、 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 系のカーネルと同様の動作をする。関連項目
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/ に書かれている。2013-04-16 | Linux |