PATH_RESOLUTION(7) Linux Programmer’s Manual PATH_RESOLUTION(7) 名前 Unix/Linux path resolution - ファイル名で参照されるファイルを見つける 説明 いくつかの Unix/Linux システムコールは、 1 つ以上のファイル名を引き数と して持つ。ファイル名 (またはパス名) は以下のようにして解決される。 ステップ 1: 解決過程を開始する パス名が '/' 文字で始まっている場合、ディレクトリ検索の開始点は呼び出し 元 のプロセスのルートディレクトリになる。 (プロセスはルートディレクトリ を親プロセスから継承する。通常は、これがファイル階層のルートディレク ト リになる。プロセスは chroot(2) システムコールを使って別のルートディレク トリを取得することもできる。この場合、そのプロセスと CLONE_NEWNS フラグ を 設定して clone(2) を呼び出すことによって開始されたそのプロセスの子孫 は、完全にプライベートなマウント名前空間を取得できる。) パス名の '/' の 部分は、このようにして扱われる。 パス名が '/' 文字で始まっていない場合、解決過程におけるディレクトリ検索 の開始点は、プロセスの現在の作業 (working) ディレクトリとなる。 (これも 親 プロセスから継承される。これは chdir(2) システムコールを使うことで変 更できる。) '/' 文字で始まるパス名は絶対パス名と呼ばれ、 '/' 文字で始まらないパス名 は相対パス名と呼ばれる。 ステップ 2: パスを辿る 現 在の検索ディレクトリをディレクトリ検索の開始点とする。そして、パス名 の最後の構成要素 (component) でない各構成要素について、現在の検索ディレ クトリで検索を行う。ここで構成要素は '/' で区切られた部分文字列である。 プロセスが現在の検索ディレクトリの検索許可を持たない場合、 EACCES エ ラ ーが返される ("Permission denied")。 構 成要素が見つからない場合、 ENOENT エラーが返される ("No such file or directory")。 構成要素は見つかったが、ディレクトリでもシンボリックリンクでもない場 合 、 ENOTDIR エラーが返される ("Not a directory")。 構 成要素が見つかって、かつディレクトリである場合、現在の検索ディレクト リをそのディレクトリに設定し、次の構成要素に移動する。 構成要素が見つかって、かつシンボリックリンク (symlink) である場合、 (現 在 の検索ディレクトリをディレクトリ検索の開始点として) 最初にそのシンボ リックリンクを解決する。結果がディレクトリでない場合、 ENOTDIR エラーが 返 される。シンボリックリンクの解決が成功してディレクトリが返された場合 、そのディレクトリを現在の検索ディレクトリとして設定し、次の構成要素 に 移 動する。解決過程に再帰が含まれる点に注意すること。カーネルをスタック オーバーフローやサービス拒否 (denial of service) から守るため、再帰の最 大 の深さとシンボリックリンクを辿る最大回数に制限がある。最大値を超えた 場合 ELOOP エラーが返される ("Too many levels of symbolic links")。 ステップ 3: 最後のエントリを見つける パス名の最後の構成要素の検索は、前のステップで説明した他の全ての構成 要 素と同じように実行されるが、2 つの違いがある。 (i) 最後の構成要素はディ レクトリである必要がない (パス解決過程に関する限りはどちらでも構わな い — 特定のシステムコールが要求するものによって、ディレクトリでなければな らない場合もあるし、ディレクトリ以外でなければならない場合 も あ る) 。 (ii) 構成要素が見つからない場合にエラーにする必要はない — その構成要素 を作成するだけでよい場合もある。最後のエントリの詳細な扱いは、特定の シ ステムコールの man ページで説明されている。 . と .. 慣習として、全てのディレクトリはエントリ "." と ".." を持つ。これらはそ れぞれ、そのディレクトリ自身とその親ディレクトリを参照する。 パス解決過程では、これらのエントリが物理的なファイルシステムに実際に 存 在するか否かに関わらず、慣習的な意味を持つと仮定する。 ルートより上に辿ることはできない: "/.." は "/" と同じである。 マウント位置 "mount dev path" コマンドを実行した後、パス名 "path" はデバイス "dev" 上のファイルシステム階層のルートディレクトリを参照するようになり、以 前 の位置を参照しない。 マ ウ ン ト さ れたファイルシステムの外に出ることができる: "path/.." は "dev" 上のファイルシステム階層の外である "path" の親ディレクトリを参 照 する。 末尾のスラッシュ パ ス名が '/' で終わっている場合、ステップ 2 において、その前にある構成 要素の解決法を次のように強制する: その構成要素が存在しなければならず 、 ディレクトリとして解決される。存在しない場合は、末尾の '/' が無視される 。 (また同様に、末尾に '/' があるパス名は、 '.' を末尾に加えて得られ る パス名と等しい。) 最後がシンボリックリンクのとき パ ス名の最後の構成要素がシンボリックリンクである場合、参照されるファイ ルをシンボリックリンクとするか、その内容についてパスを解決した結果と す る かは、システムコールに依存する。たとえば、システムコール lstat(2) は シンボリックリンクに作用する。一方、 stat(2) はシンボリックリンクで指さ れたファイルに作用する。 長さの制限 パ ス名には最大長がある。パス名 (またはシンボリックリンクを解決するとき に得られる中間パス名) が長すぎる場合、 ENAMETOOLONG エラーが返 さ れ る ("File name too long")。 空のパス名 元 々 の Unix では、空のパス名は現在のディレクトリを参照していた。最近 、POSIX では空のパス名を解決するべきではないという決定がなされた。こ の 場合、Linux は ENOENT を返す。 許可 フ ァ イ ル の許可ビットは、3 組の 3 ビットから構成される。 chmod(1) と stat(2) を参照すること。呼び出し元のプロセスの実効ユーザ ID がファイ ル の所有者 ID と等しい場合、 3 つのうち最初のグループが使われる。ファイル のグループ ID が呼び出し元のプロセスの実効グループ ID ま た は (set- groups(2) で設定される) 呼び出し元のプロセスの補助 (supplementary) グル ープ ID と等しい場合、3 つのうち 2 番目のグループが使われる。どちらにも 当てはまらない場合、3 番目のグループが使われる。 3 ビットが使われる場合、最初のビットは読み込み許可を決定し、 2 番目のビ ットは書き込み許可を決定する。また 3 番目のビットは、通常のファイルの場 合は実行許可を表し、ディレクトリの場合は検索許可を表す。 Linux は、許可のチェックにおいて、実効ユーザ ID ではなく fsuid を使う。 通常は fsuid は実効ユーザ ID と等しいが、fsuid はシステムコー ル setf- suid(2) で変更することができる。 (ここで "fsuid" は "file system user ID" を表している。この概念は「プロ セスが同じ実効ユーザ ID を持つプロセスに同時にシグナルを送ることがで き る」というユーザ空間 NFS サーバを実装する際に必要であった。これは今では 廃れてしまった。 setfsuid(2) を使うべきではない。 同様に、Linux では実効グループ ID の代わりに fsgid ("ファイルシステム・ グループID") を使う。 setfsgid(2) を参照すること。 許可の確認をスキップする: スーパーユーザとケーパビリティ 伝統的な Unix システムでは、スーパーユーザ (root, ユーザ ID 0) は非常に 強力であり、ファイルアクセス時の許可による制限を全てスキップする。 Linux では、スーパーユーザ権限が複数のケーパビリティに分割され て い る (capabilities(7) 参照)。ファイルの許可の確認には、 CAP_DAC_OVERRIDE と CAP_DAC_READ_SEARCH の 2つのケーパビリティが関係する (プロセスの fsuid が 0 の場合、そのプロセスはこれらのケーパビリティを持つ)。 CAP_DAC_OVERRIDE ケーパビリティは全ての許可チェックを上書きする。実際に は、対象となるファイルの 3 つの実行許可ビットのうちの少なくとも 1 つ が 設定されていれば、実行を許可するだけである。 CAP_DAC_READ_SEARCH ケーパビリティは、ディレクトリに対して読み込みと検 索を許可し、通常のファイルに対して読み込みを許可する。 関連項目 capabilities(7), credentials(7), symlink(7) Linux 2008-11-20 PATH_RESOLUTION(7)
PATH_RESOLUTION(7) Linux Programmer’s Manual PATH_RESOLUTION(7) NAME Unix/Linux path resolution - find the file referred to by a filename DESCRIPTION Some Unix/Linux system calls have as parameter one or more filenames. A filename (or pathname) is resolved as follows. Step 1: Start of the resolution process If the pathname starts with the '/' character, the starting lookup directory is the root directory of the calling process. (A process inherits its root directory from its parent. Usually this will be the root directory of the file hierarchy. A process may get a different root directory by use of the chroot(2) system call. A process may get an entirely private mount namespace in case it — or one of its ances- tors — was started by an invocation of the clone(2) system call that had the CLONE_NEWNS flag set.) This handles the '/' part of the path- name. If the pathname does not start with the '/' character, the starting lookup directory of the resolution process is the current working directory of the process. (This is also inherited from the parent. It can be changed by use of the chdir(2) system call.) Pathnames starting with a '/' character are called absolute pathnames. Pathnames not starting with a '/' are called relative pathnames. Step 2: Walk along the path Set the current lookup directory to the starting lookup directory. Now, for each non-final component of the pathname, where a component is a substring delimited by '/' characters, this component is looked up in the current lookup directory. If the process does not have search permission on the current lookup directory, an EACCES error is returned ("Permission denied"). If the component is not found, an ENOENT error is returned ("No such file or directory"). If the component is found, but is neither a directory nor a symbolic link, an ENOTDIR error is returned ("Not a directory"). If the component is found and is a directory, we set the current lookup directory to that directory, and go to the next component. If the component is found and is a symbolic link (symlink), we first resolve this symbolic link (with the current lookup directory as start- ing lookup directory). Upon error, that error is returned. If the result is not a directory, an ENOTDIR error is returned. If the reso- lution of the symlink is successful and returns a directory, we set the current lookup directory to that directory, and go to the next compo- nent. Note that the resolution process here involves recursion. In order to protect the kernel against stack overflow, and also to protect against denial of service, there are limits on the maximum recursion depth, and on the maximum number of symbolic links followed. An ELOOP error is returned when the maximum is exceeded ("Too many levels of symbolic links"). Step 3: Find the final entry The lookup of the final component of the pathname goes just like that of all other components, as described in the previous step, with two differences: (i) the final component need not be a directory (at least as far as the path resolution process is concerned — it may have to be a directory, or a non-directory, because of the requirements of the specific system call), and (ii) it is not necessarily an error if the component is not found — maybe we are just creating it. The details on the treatment of the final entry are described in the manual pages of the specific system calls. . and .. By convention, every directory has the entries "." and "..", which refer to the directory itself and to its parent directory, respec- tively. The path resolution process will assume that these entries have their conventional meanings, regardless of whether they are actually present in the physical file system. One cannot walk down past the root: "/.." is the same as "/". Mount points After a "mount dev path" command, the pathname "path" refers to the root of the file system hierarchy on the device "dev", and no longer to whatever it referred to earlier. One can walk out of a mounted file system: "path/.." refers to the par- ent directory of "path", outside of the file system hierarchy on "dev". Trailing slashes If a pathname ends in a '/', that forces resolution of the preceding component as in Step 2: it has to exist and resolve to a directory. Otherwise a trailing '/' is ignored. (Or, equivalently, a pathname with a trailing '/' is equivalent to the pathname obtained by appending '.' to it.) Final symlink If the last component of a pathname is a symbolic link, then it depends on the system call whether the file referred to will be the symbolic link or the result of path resolution on its contents. For example, the system call lstat(2) will operate on the symlink, while stat(2) operates on the file pointed to by the symlink. Length limit There is a maximum length for pathnames. If the pathname (or some intermediate pathname obtained while resolving symbolic links) is too long, an ENAMETOOLONG error is returned ("File name too long"). Empty pathname In the original Unix, the empty pathname referred to the current direc- tory. Nowadays POSIX decrees that an empty pathname must not be resolved successfully. Linux returns ENOENT in this case. Permissions The permission bits of a file consist of three groups of three bits, cf. chmod(1) and stat(2). The first group of three is used when the effective user ID of the calling process equals the owner ID of the file. The second group of three is used when the group ID of the file either equals the effective group ID of the calling process, or is one of the supplementary group IDs of the calling process (as set by set- groups(2)). When neither holds, the third group is used. Of the three bits used, the first bit determines read permission, the second write permission, and the last execute permission in case of ordinary files, or search permission in case of directories. Linux uses the fsuid instead of the effective user ID in permission checks. Ordinarily the fsuid will equal the effective user ID, but the fsuid can be changed by the system call setfsuid(2). (Here "fsuid" stands for something like "file system user ID". The concept was required for the implementation of a user space NFS server at a time when processes could send a signal to a process with the same effective user ID. It is obsolete now. Nobody should use setf- suid(2).) Similarly, Linux uses the fsgid ("file system group ID") instead of the effective group ID. See setfsgid(2). Bypassing permission checks: superuser and capabilities On a traditional Unix system, the superuser (root, user ID 0) is all- powerful, and bypasses all permissions restrictions when accessing files. On Linux, superuser privileges are divided into capabilities (see capa- bilities(7)). Two capabilities are relevant for file permissions checks: CAP_DAC_OVERRIDE and CAP_DAC_READ_SEARCH. (A process has these capabilities if its fsuid is 0.) The CAP_DAC_OVERRIDE capability overrides all permission checking, but only grants execute permission when at least one of the file’s three execute permission bits is set. The CAP_DAC_READ_SEARCH capability grants read and search permission on directories, and read permission on ordinary files. SEE ALSO capabilities(7), credentials(7), symlink(7) COLOPHON This page is part of release 3.22 of the Linux man-pages project. A description of the project, and information about reporting bugs, can be found at http://www.kernel.org/doc/man-pages/. Linux 2008-11-20 PATH_RESOLUTION(7)
Copyright(C) linux-cmd.com All Rights Reserved. Author Takayuki Yukawa