名前¶

説明¶

ACL タイプ¶

ACL エントリ¶

ACL エントリには、エントリタグ型・ オプションとしてのエントリタグ修飾子 (qualifier)・許可の集合が含まれる。 ここでは、修飾子という単語を ACL エントリのエントリタグ修飾子を表すのに使う。

修飾子は、ACL_USER または ACL_GROUP というタグ型のエントリに対して、 それぞれユーザまたはグループの識別子を表す。 ACL_USER と ACL_GROUP 以外のタグ型のエントリは、 定義された修飾子を持たない。

以下のエントリタグ型が定義されている:

アクセスチェックが実行される場合、実効 (effective) ユーザ ID に対して ACL_USER_OBJ と ACL_USER エントリがテストされる。 実効グループ ID は、全ての補助 (supplementary) グループ ID と同様に、 ACL_GROUP_OBJ と ACL_GROUP エントリに対してテストされる。

有効な ACL¶

全てのユーザ ID 修飾子は、ACL_USER タグ型の全てのエントリにおいて 一意でなければならない。 また全てのグループ ID 修飾子は、ACL_GROUP タグ型の全てのエントリにおいて 一意でなければならない。

acl_get_file() 関数は、ディレクトリにデフォルト ACL が関連付けられていない場合、 ディレクトリのデフォルト ACL として、 ACL エントリが 1 つも 含まれない ACL を返す。 acl_set_file() 関数も、ACL エントリが 1 つも含まない ACL を、 ディレクトリに対する有効 なデフォルト ACL として受け付ける。 このような ACL はディレクトリに デフォルト ACL を関連付けないことを表す。 これは acl_delete_def_file() 関数を使うのと等価である。

ACL エントリとファイル許可ビットの対応¶

ファイルの所有者、グループ、その他のユーザに対する許可 (permission) と特定の ACL エントリには対応関係がある。ファイル所有者に対して定義される許可は、 ACL_USER_OBJ エントリの許可に対応する。 ACL に ACL_MASK エントリがある場合、ファイルグループに対して定義される許可は、 ACL_MASK エントリの許可に対応する。 ACL に ACL_MASK エントリがない場合、ファイルグループに対して定義される許可は、 ACL_GROUP_OBJ エントリの許可に対応する。その他のユーザに対して定義される許可は、 ACL_OTHER_OBJ エントリの許可に対応する。

ファイルの所有者、グループ、その他のユーザに対する許可は、対応する ACL エントリの許可と常に一致する。ファイル許可ビットを変更すると、関連付けられた ACL エントリが変更される。 ACL エントリの許可を変更すると、ファイル許可ビットが変更される。

オブジェクトの作成とデフォルト ACL¶

1. 新しいオブジェクトは、それが含まれるディレクトリのデフォルト ACL を アクセス ACL として継承する。
2. ファイル許可ビットに対応するアクセス ACL エントリが修正され、 mode 引き数で指定されていない許可ビットを含まないようにされる。

ディレクトリにデフォルト ACL が関連付けられていない場合、 ファイルオブジェクトを作成する関数の mode 引き数とファイル作成マスク (umask(2) を参照) を使って、新しいオブジェクトの ACL が決定される:

1. 新しいオブジェクトには、タグ型 ACL_USER_OBJ, ACL_GROUP_OBJ, ACL_OTHER の エントリを含むアクセス ACL が割り当てられる。 これらのエントリの許可は、ファイル作成マスクで指定された許可に設定される。
2. ファイル許可ビットに対応するアクセス ACL エントリが修正され、 mode 引き数で指定されていない許可ビットを含まないようにされる。

アクセスチェックアルゴリズム¶

1. If プロセスの実効ユーザ ID がファイルオブジェクト所有者のユーザ ID と一致する。 then
   if 要求された許可が ACL_USER_OBJ エントリに含まれるならば、アクセスは許可される。

   else アクセスは拒否される。

2. else if プロセスの実効ユーザ ID が ACL_USER 型の何れかのエントリの修飾子と一致する。 then
   if 一致した ACL_USER エントリと ACL_MASK エントリに 要求された許可が含まれるならば、アクセスは許可される。

   else アクセスは拒否される。

3. else if プロセスの実効グループ ID または何れかの補助グループ ID が、 ファイルグループまたは ACL_GROUP 型の何れかのエントリの修飾子と一致する。 then
   if ACL が ACL_MASK エントリを含む。 then

   if ACL_MASK エントリおよび一致する ACL_GROUP_OBJ または ACL_GROUP エントリの 何れかに、要求された許可が含まれるならば、アクセスは許可される。

   else アクセスは拒否される。

   else (ACL_MASK エントリを含まない ACL_GROUP エントリは存在しない点に注意すること)

   if ACL_GROUP_OBJ エントリが要求された許可を含むならば、アクセスは許可される。

   else アクセスは拒否される。

4. else if ACL_OTHER エントリが要求された許可を含むならば、アクセスは許可される。
5. else アクセスは拒否される。

ACL テキスト形式¶

2 番目のフィールドは、 エントリタグ型 ACL_USER または ACL_GROUP のエントリの場合、 ACL エントリに関連付けられているユーザまたはグループ識別子を含む。 その他のエントリの場合、このフィールドは空になる。 ユーザ識別子はユーザ名でも 10 進数のユーザ ID 番号でもよい。 グループ識別子はグループ名でも 10 進数のグループ ID 番号でもよい。

3 番目のフィールドは任意のアクセス許可を保持する。 書き出し・読み込み・検索／実行の許可は、 r, w, x という文字でこの順番で表される。 ACL エントリにこれらの許可がない場合、各文字は - 文字で置き換えられる。 テキスト形式から内部表現に変換する場合、 保持していない許可は指定する必要がない。

各 ACL エントリの始めと終わり、そして フィールド区切り文字 (コロン文字) の直前と直後には、 空白を入れることができる。

user::rw-
user:lisa:rw-         #effective:r--
group::r--
group:toolies:rw-     #effective:r--
mask::r--
other::r--

u::rw-,u:lisa:rw-,g::r--,g:toolies:rw-,m::r--,o::r--
g:toolies:rw,u:lisa:rw,u::wr,g::r,o::r,m::r

理論的根拠¶

ファイルユーティリティの変更¶

• デフォルト ACL を持つファイル、または必要とされる 3 つ以上の ACL エントリを 保持するアクセス ACL を持つファイルに対して、 ls(1) ユーティリティを長い形式 ls -l で実行すると、 プラス記号 (+) が許可文字列の後に表示される。
• -p フラグが指定された場合、 cp(1) ユーティリティは ACL も保存する。 保存できない場合は警告が出される。
• mv(1) ユーティリティは常に ACL を保存する。 保存できない場合は警告が出される。

chmod(1) ユーティリティと chmod(2) システムコールのアクセス ACL に対する影響については、 「ACL エントリとファイル許可ビットの対応」 で説明されている。

準拠¶

Linux アクセス制御リストは、 POSIX.1e のアクセス制御リストで定義されている全ての関数セットと いくつかの拡張を実装している。 この実装は POSIX.1e draft 17 に完全に準拠する。 拡張にはその旨が記されている。 アクセス制御リストの操作関数は、 ACL ライブラリ (libacl, -lacl) で定義されている。 POSIX 互換のインタフェースは <sys/acl.h> ヘッダで宣言されている。 これらの関数に対する Linux 固有の拡張は、 <acl/libacl.h> ヘッダで宣言されている。

関連項目¶

著者¶