kazmax - Linux で自宅サーバー

access - システムコールの説明 - Linux コマンド集 一覧表

  1. 名前
  2. 書式
  3. 説明
  4. 返り値
  5. エラー
  6. 制限
  7. 準拠
  8. 関連項目

名前

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

書式

#include <unistd.h>

int access(const char *pathname, int mode);

説明

access ()は pathname という名前を持つファイル (または他のファイル・システム上のオブジェクト) に対して、プロセスからの読み出し・書き込みが許されているか、 ファイルが存在しているかなどのチェックを行なう。 pathname がシンボリック・リンクならば、このシンボリック・リンクの参照する ファイルに対するアクセス権が検査される。
modeR_OK , W_OK , X_OK , F_OK の一つ以上から構成されるマスクである。
R_OK , W_OK , X_OK はそれぞれ 「ファイルが存在して読み込み許可があるか」 「ファイルが存在して書き込み許可があるか」 「ファイルが存在して実行許可があるか」 のチェックを要求する。 F_OK はファイルが存在するかどうかのみをチェックするよう要求する。
検査は pathname で指定されたファイルへのパスに現れるディレクトリのアクセス権に依存する。 また、シンボリック・リンクの参照を行う途中で出会う、 ディレクトリやファイルのアクセス権にも依存する。
チェックは、実際の操作で使用するプロセスの実効 (effective) ID でなく "実 (real)" UID や "実 (real)" GID で行なわれる。 これは set-user-ID プログラムで、実行ユーザの権限を決定しやすく するためである。
アクセス・ビットのみがチェックされ、ファイルの種類や内容はチェックされない。 従って、ディレクトリが「書き込み可能」となった場合は、ディレクトリに ファイルを作成することが可能なことを意味するのであり、ディレクトリに ファイルとして書き込むことが可能なわけではない。 同様に DOS のファイルは「実行可能」と判断されるが、   execve (2) コールは失敗するだろう。
プロセスが適切な権限を持っている場合、 ファイルの実行許可ビットがひとつもセットされていなくても、 X_OK を返す実装もある。

返り値

成功した場合(全ての要求された許可が得られたら)、ゼロが返される。 エラーの場合 (少なくとも一つの mode で要求された許可がなかった場合や、他のエラーが起きた場合)、 -1 が返され、 errno が適切に設定される。

エラー

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

EACCES
要求されたアクセスは そのファイル自身に拒否されたか pathname へ至るまでディレクトリのいずれかに対する検索許可 (search permission) が得られなかった。 ( path_resolution (2)も参照のこと)
ELOOP
pathname を解決する際に遭遇したシンボリック・リンクが多過ぎる。
ENAMETOOLONG
pathname が長過ぎる。
ENOENT
pathname のディレクトリ部分はアクセス可能であっただろうが、 ファイルが存在しないか、参照先のない (dangling) シンボリックリンクに なっている。
ENOTDIR
pathname のディレクトリ部分が、実際にはディレクトリでない。
EROFS
読み込み専用 (read-only) のファイル・システムに対して書き込み許可を 要求した。

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

EFAULT
pathname がアクセス可能なアドレス空間の外を指している。
EINVAL
mode に不正な値が指定された。
EIO
I/O エラーが発生した。
ENOMEM
カーネルに十分なメモリがない。
ETXTBSY
実行中のファイルに対して書き込みを要求した。

制限

access ()は要求されたアクセス種別のいずれかのチェックに失敗した場合には、 たとえ他の種別のチェックが成功したとしてもエラーを返す。

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

あるユーザが、例えば   open (2) によるアクセスが可能かどうかを、(実際に行う前に) access ()を使ってチェックするのは、セキュリティホールの原因になる。 なぜならチェックをしてから 実際にファイルのオープン操作をする間の短い間隔を悪用できるからである。

準拠

SVr4, POSIX.1-2001, 4.3BSD

関連項目