[top]#

|http://www.google.com/[Google] | a|

Web

This Site

初心者向けのUnix *

高度なUnix *

選択した読書

http://www.finddevguides.com/computer_glossary [コンピュータ用語集]
Who is Who

[cols=",,,,,,,",]

[width="100%",cols="100%",]

a| == path_resolution（）-Unix、Linuxシステムコール

[[File:]] image ：http：//www.finddevguides.com/images/next.gif [next] image:http://www.finddevguides.com/add- this.gif [AddThisソーシャルブックマークボタン]

NAME

Unix/Linuxパス解決-ファイル名で参照されるファイルを見つける

説明

一部のUnix/Linuxシステムコールには、パラメータとして1つ以上のファイル名があります。ファイル名（またはパス名）は次のように解決されます。

ステップ1：解決プロセスの開始

パス名が「/」文字で始まる場合、開始ルックアップディレクトリは現在のプロセスのルートディレクトリです。（プロセスは、その親からルートディレクトリを継承します。通常、これはファイル階層のルートディレクトリになります。プロセスは、 chroot （2）システムコールを使用して別のルートディレクトリを取得できます。プロセスは、CLONE_NEWNSフラグが設定された clone （2）システムコールの呼び出しによって、またはその祖先の1つが開始された場合、完全にプライベートな名前空間を取得する場合があります。パス名。

パス名が「/」文字で始まっていない場合、解決プロセスの開始ルックアップディレクトリは、プロセスの現在の作業ディレクトリです。（これも親から継承されます。 chdir （2）システムコールを使用して変更できます。）

「/」文字で始まるパス名は、絶対パス名と呼ばれます。「/」で始まらないパス名は相対パス名と呼ばれます。

ステップ2：パスに沿って歩く

現在の検索ディレクトリを開始検索ディレクトリに設定します。現在、パス名の非最終コンポーネント（コンポーネントは「/」文字で区切られたサブストリング）ごとに、このコンポーネントは現在のルックアップディレクトリで検索されます。

プロセスに現在のルックアップディレクトリに対する検索権限がない場合、EACCESエラーが返されます（「Permission denied」）。

コンポーネントが見つからない場合、ENOENTエラーが返されます（ "No such file or directory"）。

コンポーネントは見つかったが、ディレクトリでもシンボリックリンクでもない場合、ENOTDIRエラーが返されます（ "Not a directory"）。

コンポーネントが見つかってディレクトリである場合、現在の検索ディレクトリをそのディレクトリに設定し、次のコンポーネントに進みます。

コンポーネントが見つかり、シンボリックリンク（symlink）である場合、最初にこのシンボリックリンクを（現在のルックアップディレクトリを開始ルックアップディレクトリとして）解決します。エラーが発生すると、そのエラーが返されます。結果がディレクトリでない場合、ENOTDIRエラーが返されます。シンボリックリンクの解決が成功してディレクトリを返す場合、現在の検索ディレクトリをそのディレクトリに設定し、次のコンポーネントに進みます。ここでの解決プロセスには再帰が含まれることに注意してください。スタックオーバーフローからカーネルを保護し、サービス拒否からも保護するために、最大再帰深度と、その後に続くシンボリックリンクの最大数に制限があります。 ELOOPエラーは、最大値を超えたときに返されます（「シンボリックリンクのレベルが多すぎます」）。

ステップ3：最終エントリを見つける

パス名の最終コンポーネントのルックアップは、前のステップで説明した他のすべてのコンポーネントのルックアップとまったく同じですが、2つの違いがあります：（i）最終コンポーネントはディレクトリである必要はありません（少なくともパス解決プロセスまで）特定のシステムコールの要件により、ディレクトリまたは非ディレクトリである必要があります）、および（ii）コンポーネントが見つからない場合は必ずしもエラーではありませんそれ。最終エントリの処理の詳細は、特定のシステムコールのマニュアルページに記載されています。

. および..

慣例により、すべてのディレクトリにはエントリ「。」があります。「..」は、それぞれディレクトリ自体とその親ディレクトリを指します。

パス解決プロセスは、物理ファイルシステムに実際に存在するかどうかに関係なく、これらのエントリに従来の意味があると想定します。

ルートを通り抜けることはできません。「/..」は「/」と同じです。

マウントポイント

「mount dev path」コマンドの後、パス名「path」はデバイス「dev」上のファイルシステム階層のルートを参照し、以前に参照したものをもはや参照しません。

マウントされたファイルシステムから抜け出すことができます。「path/..」は、「dev」のファイルシステム階層外の「path」の親ディレクトリを指します。

末尾のスラッシュ

パス名が「/」で終わる場合、ステップ2のように、先行するコンポーネントの解決が強制されます。このコンポーネントは存在し、ディレクトリに解決する必要があります。それ以外の場合、末尾の「/」は無視されます。（または、同様に、末尾に「/」が付いたパス名は、「。」を追加したパス名と同等です。）

最終シンボリックリンク

パス名の最後のコンポーネントがシンボリックリンクである場合、参照されるファイルがシンボリックリンクであるか、そのコンテンツのパス解決の結果であるかは、システムコールに依存します。たとえば、システムコール lstat （2）はシンボリックリンクで動作し、 stat （2）はシンボリックリンクが指すファイルで動作します。

長さの制限

パス名には最大長があります。パス名（またはシンボリックリンクの解決中に取得された中間パス名）が長すぎる場合、ENAMETOOLONGエラーが返されます（「ファイル名が長すぎます」）。

空のパス名

元のUnixでは、空のパス名は現在のディレクトリを参照していました。最近のPOSIXでは、空のパス名を正常に解決してはならないと定めています。この場合、LinuxはENOENTを返します。

Permissions

ファイルの許可ビットは、3ビットの3つのグループで構成されます、cf。 chmod （1）および stat （2）。 3つの最初のグループは、現在のプロセスの実効ユーザーIDがファイルの所有者IDと等しい場合に使用されます。 3番目の2番目のグループは、ファイルのグループIDが現在のプロセスの実効グループIDに等しいか、現在のプロセスの補助グループIDのいずれか（ setgroups （2）で設定）の場合に使用されます。どちらも成立しない場合、3番目のグループが使用されます。

使用される3ビットのうち、最初のビットは、読み取り許可、2番目の書き込み許可、通常のファイルの場合は最後の実行許可、ディレクトリの場合は検索許可を決定します。

Linuxは、権限チェックで実効ユーザーIDの代わりにfsuidを使用します。通常、fsuidは実効ユーザーIDと等しくなりますが、fsuidはシステムコール setfsuid （2）で変更できます。

（ここで「fsuid」は「ファイルシステムユーザー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機能は、ディレクトリの読み取りおよび検索許可、および通常のファイルの読み取り許可を付与します。

Unix-system-calls-path-resolution