acl —
アクセス制御リスト
(Access Control Lists)
この man ページは POSIX
アクセス制御リストについて説明している。
ACL
はファイルとディレクトリに対して、
より洗練された任意アクセス権
(discretionary access right) を
定義するのに使われる。
全てのオブジェクトは、そのオブジェクトに対する任意のアクセスを決定する
ACL
に関連付けられていると考えることができる。
この ACL はアクセス AC
と呼ばれる。
これに加えて、ディレクトリに関連付けられた
ACL がある。 この ACL
はディレクトリ内で作成されたオブジェクトの
最初のアクセス ACL
を決定する。 この ACL
はデフォルト ACL
と呼ばれる。
ACL は ACL
エントリの集合で構成される。
ACL
エントリは、それが関連付けられたオブジェクトの
アクセス許可 (permission)
を指定する。
アクセス許可は、個々のユーザまたはユーザのグループに対する
読み出し・書き込み・検索／実行の許可の組み合わせである。
ACL
エントリには、エントリタグ型・
オプションとしてのエントリタグ修飾子
(qualifier)・許可の集合が含まれる。
ここでは、修飾子という単語を
ACL
エントリのエントリタグ修飾子を表すのに使う。
修飾子は、ACL_USER または
ACL_GROUP
というタグ型のエントリに対して、
それぞれユーザまたはグループの識別子を表す。
ACL_USER と ACL_GROUP
以外のタグ型のエントリは、
定義された修飾子を持たない。
以下のエントリタグ型が定義されている:
- ACL_USER_OBJ
- ACL_USER_OBJ
エントリはファイル所有者に対するアクセス権を表す。
- ACL_USER
- ACL_USER
エントリはエントリの修飾子で識別されるユーザに対するアクセス権を表す。
- ACL_GROUP_OBJ
- ACL_GROUP_OBJ
エントリはファイルグループに対するアクセス権を表す。
- ACL_GROUP
- ACL_GROUP
エントリはエントリの修飾子で識別される
グループに対するアクセス権を表す。
- ACL_MASK
- ACL_MASK エントリは ACL_USER,
ACL_GROUP_OBJ, ACL_GROUP
型のエントリで
許可される最大のアクセス権を表す。
- ACL_OTHER
- ACL_OTHER エントリは ACL
における他のどのエントリともマッチしない
プロセスのアクセス権を表す。
アクセスチェックが実行される場合、実効
(effective) ユーザ ID に対して
ACL_USER_OBJ と ACL_USER
エントリがテストされる。
実効グループ ID
は、全ての補助 (supplementary)
グループ ID と同様に、
ACL_GROUP_OBJ と ACL_GROUP
エントリに対してテストされる。
有効な ACL には ACL_USER_OBJ, ACL_GROUP_OBJ,
ACL_OTHER タグ型のうち
何れか 1
つだけのエントリが含まれる。
ACL_USER と ACL_GROUP
タグ型のエントリは、
0 回以上 ACL
に出現することができる。
ACL_USER または ACL_GROUP
タグ型のエントリを含む
ACL は、 ACL_MASK
タグ型のエントリを 1
つだけ含まなければならない。
ACL_USER または ACL_GROUP
タグ型のエントリが ACL
に含まれない場合、
ACL_MASK
エントリはオプションである。
全てのユーザ 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
で定義される許可は、ファイル許可ビットで指定される許可の上位集合
(superset) である。
ファイルの所有者、グループ、その他のユーザに対する許可
(permission) と特定の ACL
エントリには対応関係がある。ファイル所有者に対して定義される許可は、
ACL_USER_OBJ
エントリの許可に対応する。
ACL に ACL_MASK
エントリがある場合、ファイルグループに対して定義される許可は、
ACL_MASK
エントリの許可に対応する。
ACL に ACL_MASK
エントリがない場合、ファイルグループに対して定義される許可は、
ACL_GROUP_OBJ
エントリの許可に対応する。その他のユーザに対して定義される許可は、
ACL_OTHER_OBJ
エントリの許可に対応する。
ファイルの所有者、グループ、その他のユーザに対する許可は、対応する
ACL
エントリの許可と常に一致する。ファイル許可ビットを変更すると、関連付けられた
ACL
エントリが変更される。
ACL
エントリの許可を変更すると、ファイル許可ビットが変更される。
ファイルオブジェクトのアクセス
ACL は、
creat(),
mkdir(),
mknod(),
mkfifo(),
open()
関数のいずれかでオブジェクトが作られたときに初期化される。
デフォルト ACL
がディレクトリと関連付けられている場合、
ファイルオブジェクトを作成する関数の
mode
引き数とディレクトリのデフォルト
ACL を使って、
新しいオブジェクトの
ACL が決定される:
- 新しいオブジェクトは、それが含まれるディレクトリのデフォルト
ACL を アクセス ACL
として継承する。
- ファイル許可ビットに対応するアクセス
ACL
エントリが修正され、
mode
引き数で指定されていない許可ビットを含まないようにされる。
ディレクトリにデフォルト
ACL
が関連付けられていない場合、
ファイルオブジェクトを作成する関数の
mode
引き数とファイル作成マスク
(
umask(2) を参照)
を使って、新しいオブジェクトの
ACL が決定される:
- 新しいオブジェクトには、タグ型
ACL_USER_OBJ, ACL_GROUP_OBJ, ACL_OTHER の
エントリを含むアクセス
ACL
が割り当てられる。
これらのエントリの許可は、ファイル作成マスクで指定された許可に設定される。
- ファイル許可ビットに対応するアクセス
ACL
エントリが修正され、
mode
引き数で指定されていない許可ビットを含まないようにされる。
プロセスは、ACL
で保護されたファイルオブジェクトに対して、
読み出し・書き込み・実行／検索を要求することができる。
アクセスチェックアルゴリズムは
オブジェクトへのアクセスを許可するか否かを決定する。
-
If
プロセスの実効ユーザ
ID
がファイルオブジェクト所有者のユーザ
ID と一致する。
then
if
要求された許可が
ACL_USER_OBJ
エントリに含まれるならば、アクセスは許可される。
else
アクセスは拒否される。
-
else if
プロセスの実効ユーザ
ID が ACL_USER
型の何れかのエントリの修飾子と一致する。
then
if
一致した ACL_USER
エントリと ACL_MASK
エントリに
要求された許可が含まれるならば、アクセスは許可される。
else
アクセスは拒否される。
-
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
アクセスは拒否される。
-
else if ACL_OTHER
エントリが要求された許可を含むならば、アクセスは許可される。
-
else
アクセスは拒否される。
ACL
を表現するために長いテキスト形式と短いテキスト形式が定義されている。
両方の形式において、ACL
エントリはコロン区切られた
3 つのフィールド、 ACL
エントリタグ型・ACL
エントリ修飾子・任意のアクセス許可で表現される。
1
番目のフィールドは以下のエントリタグ型キーワードの何れかを含む:
user-
user
ACL
エントリは、ファイル所有者
(エントリタグ型 ACL_USER_OBJ)
と 指定されたユーザ
(エントリタグ型 ACL_USER)
に対して
許可されるアクセスを指定する。
group-
group
ACL
エントリは、ファイルグループ
(エントリタグ型 ACL_GROUP_OBJ)
と
指定されたグループ
(エントリタグ型 ACL_GROUP)
に対して
許可されるアクセスを指定する。
mask-
mask
ACL
エントリは、ファイル所有者に対する
user エントリと
other
エントリを除く、
全ての ACL
(エントリタグ型 ACL_MASK)
に対して許可されるアクセスのうち
最大のものを指定する。
other-
other
ACL エントリは、どの
user ACL
エントリにも
group ACL
エントリにもマッチしない
(エントリタグ型 ACL_OTHER)
の
プロセスに対して許可されるアクセスを指定する。
2
番目のフィールドは、
エントリタグ型 ACL_USER
または ACL_GROUP
のエントリの場合、 ACL
エントリに関連付けられているユーザまたはグループ識別子を含む。
その他のエントリの場合、このフィールドは空になる。
ユーザ識別子はユーザ名でも
10 進数のユーザ ID
番号でもよい。
グループ識別子はグループ名でも
10 進数のグループ ID
番号でもよい。
3
番目のフィールドは任意のアクセス許可を保持する。
書き出し・読み込み・検索／実行の許可は、
r,
w,
x
という文字でこの順番で表される。
ACL
エントリにこれらの許可がない場合、各文字は
-
文字で置き換えられる。
テキスト形式から内部表現に変換する場合、
保持していない許可は指定する必要がない。
各 ACL
エントリの始めと終わり、そして
フィールド区切り文字
(コロン文字)
の直前と直後には、
空白を入れることができる。
長いテキスト形式では、1
行に 1 つの ACL
エントリを保持する。
さらにナンバー記号
(
#)
でコメントを開始することが可能で、行の終りまでがコメントになる。
ACL_MASK
エントリに含まれない許可が
ACL_USER, ACL_GROUP_OBJ, ACL_GROUP ACL
エントリに含まれる場合、
そのエントリの後にはナンバー記号と文字列
“effective:” と
そのエントリで定義される実効アクセス許可が続く。
以下は長いテキスト形式の例である:
user::rw-
user:lisa:rw- #effective:r--
group::r--
group:toolies:rw- #effective:r--
mask::r--
other::r--
短いテキスト形式は、コンマで区切られた
ACL
エントリの並びであり、
入力として使われる。
コメントはサポートされていない。
エントリタグ型キーワードは省略されない完全な形式でも
1
文字の省略形でも指定できる。
user の省略形は
u,
group
の省略形は
g,
mask の省略形は
m,
other
の省略形は
o
である。 許可には、
r,
w,
x
という文字のうち 1
つ以上を、任意の順番で含めることができる。
以下は短いテキスト形式の例である:
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
IEEE 1003.1e draft 17 は、 タグ型 ACL_MASK
のエントリを含むアクセス制御リストを定義しており、
画一的ではないファイル許可ビット間の対応付けを定義している。
標準化作業グループは、IEEE
1003.1 (“POSIX.1”)
と互換性のない
アプリケーションが ACL
を持つシステム上でも機能することを保証するために、
比較的複雑なインタフェースを定義した。
IEEE 1003.1e draft 17
には、このインタフェースを選択する理論的根拠が
セクション B.23
に書かれている。
ACL
をサポートするシステムでは、ファイルユーティリティ
ls(1),
cp(1),
mv(1)
は自身の動作を以下のように変更する:
- デフォルト ACL
を持つファイル、または必要とされる
3 つ以上の ACL
エントリを
保持するアクセス ACL
を持つファイルに対して、
ls(1)
ユーティリティを長い形式
ls -l
で実行すると、
プラス記号 (
+)
が許可文字列の後に表示される。
-
-p
フラグが指定された場合、
cp(1)
ユーティリティは ACL
も保存する。
保存できない場合は警告が出される。
-
mv(1)
ユーティリティは常に
ACL を保存する。
保存できない場合は警告が出される。
chmod(1)
ユーティリティと
chmod(2)
システムコールのアクセス
ACL
に対する影響については、
「ACL
エントリとファイル許可ビットの対応」
で説明されている。
IEEE 1003.1e draft 17 (“POSIX.1e”) は、 IEEE 1003.1
標準に対するいくつかのセキュリティ拡張について記述している。
1003.1e
での作業は放棄されたが、多くの
UNIX 系システムは POSIX.1e draft 17
またはそれ以前のドラフトの一部を実装している。
Linux
アクセス制御リストは、
POSIX.1e
のアクセス制御リストで定義されている全ての関数セットと
いくつかの拡張を実装している。
この実装は POSIX.1e draft 17
に完全に準拠する。
拡張にはその旨が記されている。
アクセス制御リストの操作関数は、
ACL ライブラリ (libacl, -lacl)
で定義されている。 POSIX
互換のインタフェースは
<sys/acl.h>
ヘッダで宣言されている。
これらの関数に対する
Linux 固有の拡張は、
<acl/libacl.h>
ヘッダで宣言されている。
chmod(1),
creat(2),
getfacl(1),
ls(1),
mkdir(2),
mkfifo(2),
mknod(2),
open(2),
setfacl(1),
stat(2),
umask(1)
http://www.guug.de/~winni/posix.1e/download.html
- ACL
ストレージの管理
-
acl_dup(3),
acl_free(3),
acl_init(3)
- ACL
エントリの操作
-
acl_copy_entry(3),
acl_create_entry(3),
acl_delete_entry(3),
acl_get_entry(3),
acl_valid(3)
acl_add_perm(3),
acl_calc_mask(3),
acl_clear_perms(3),
acl_delete_perm(3),
acl_get_permset(3),
acl_set_permset(3)
acl_get_qualifier(3),
acl_get_tag_type(3),
acl_set_qualifier(3),
acl_set_tag_type(3)
- オブジェクトの
ACL の操作
-
acl_delete_def_file(3),
acl_get_fd(3),
acl_get_file(3),
acl_set_fd(3),
acl_set_file(3)
- ACL
形式の変換
-
acl_copy_entry(3),
acl_copy_ext(3),
acl_from_text(3),
acl_to_text(3),
acl_size(3)
最初の関数のグループは
POSIX
ライクなアクセス制御リストを持つ
大部分のシステムでサポートされている。
一方、2
番目の関数のグループをサポートしているシステムは少ない。
移植を予定するアプリケーションでは、2
番目のグループを避けた方が良い。
acl_delete_def_file(3),
acl_dup(3),
acl_free(3),
acl_from_text(3),
acl_get_fd(3),
acl_get_file(3),
acl_init(3),
acl_set_fd(3),
acl_set_file(3),
acl_to_text(3),
acl_valid(3)
acl_add_perm(3),
acl_calc_mask(3),
acl_clear_perms(3),
acl_copy_entry(3),
acl_copy_ext(3),
acl_copy_int(3),
acl_create_entry(3),
acl_delete_entry(3),
acl_delete_perm(3),
acl_get_entry(3),
acl_get_permset(3),
acl_get_qualifier(3),
acl_get_tag_type(3),
acl_set_permset(3),
acl_set_qualifier(3),
acl_set_tag_type(3),
acl_size(3)
これらの移植性のない拡張は、Linux
システムでのみ有効である。
acl_check(3),
acl_cmp(3),
acl_entries(3),
acl_equiv_mode(3),
acl_error(3),
acl_extended_fd(3),
acl_extended_file(3),
acl_extended_file_nofollow(3),
acl_from_mode(3),
acl_get_perm(3),
acl_to_any_text(3)
Andreas Gruenbacher, <
[email protected]>