以前のバージョンの Solaris OS では、主に POSIX ドラフト ACL 仕様に基づく ACL 実装がサポートされていました。POSIX ドラフトに基づく ACL は、UFS ファイルを保護するために使用され、NFSv4 より前のバージョンの NFS によって変換されます。
NFSv4 を導入したことにより、NFSv4 が提供する UNIX クライアントとUNIX 以外のクライアントとの間の相互運用性を、新しい ACL モデルを使って完全にサポートできるようになりました。NFSv4 仕様で定義されている新しい ACL 実装は、NT 方式の ACL を使用して、より豊かなセマンティクスを実現します。
新しい ACL モデルの主な相違点は、次のとおりです。
新しい ACL モデルは NFSv4 仕様に基づいており、NT 形式の ACL に似ています。
新しいモデルは、より詳細なアクセス権を提供します。詳細は、表 8–2 を参照してください。
ACL は、setfacl や getfacl コマンドではなく、chmod および ls コマンドを使用して設定および表示します。
新しいモデルは、ディレクトリからサブディレクトリへとアクセス特権が適用されていく方法に対して、より豊富な継承セマンティクスを提供します。詳細については、「ACL 継承」を参照してください。
どちらの ACL モデルを使った場合でも、標準のファイルアクセス権の場合より詳細にアクセス権を制御できます。新しい ACL は、POSIX ドラフト ACL と同様に、複数のアクセス制御エントリ (ACE) で構成されています。
POSIX ドラフトに基づく ACL では、1 つのエントリを使用して、許可するアクセス権と拒否するアクセス権を定義します。新しい ACL モデルでは、アクセス権を検査するために、2 種類の ACE が利用されます。 ALLOW と DENY です。つまり、どちらの ACE にもアクセス権が定義されていますが、その ACE に定義されていないアクセス権については、その ACE だけを使ってアクセス権を許可または拒否するかを推論することはできません。
NFSv4 ACL と POSIX ドラフト ACLとの 間の変換は、次のように行われます。
ACL に対応するユーティリティー (cp、mv、tar、cpio、rcp コマンドなど) を使用している場合は、ACL が含まれる UFS ファイルを ZFS ファイルシステムに転送するときに、POSIX ドラフト ACL が同等の NFSv4 ACL に変換されます。
一部の NFSv4 ACL は、POSIX ドラフト ACL に変換されます。NFSv4 ACL が POSIX ドラフト ACL に変換されない場合は、次のようなメッセージが表示されます。
# cp -p filea /var/tmp cp: failed to set acl entries on /var/tmp/filea |
最新の Solaris リリースを実行するシステム上で ACL の保持オプション (tar -p または cpio -P) を使って UFS tar または cpio アーカイブを作成した場合でも、以前の Solaris リリースを実行するシステム上でそのアーカイブを展開したときは、ACL が失われます。
すべてのファイルが正しいファイルモードで展開されますが、ACL エントリは無視されます。
ufsrestore コマンドを使って ZFS ファイルシステムにデータを復元することができます。元のデータに POSIX ドラフト ACL が含まれている場合、それらは NFSv4 ACL に変換されます。
UFS ファイルに NFSv4 ACL を設定しようとすると、次のようなメッセージが表示されます。
chmod: ERROR: ACL type's are different |
ZFS ファイルに POSIX ドラフト ACL を設定しようとすると、次のようなメッセージが表示されます。
# getfacl filea File system doesn't support aclent_t style ACL's. See acl(5) for more information on Solaris ACL support. |
ACL およびバックアップ製品に関するその他の制限については、「ほかのバックアップ製品を使用して ZFS データを保存する」を参照してください。
簡易 ACL を設定する構文
この ACL は、従来の UNIX の owner/group/other エントリを表現しているだけという点で、「簡易な」ACLです。
chmod [options] A[index]{+|=}owner@ |group@ |everyone@: access-permissions/...[:inheritance-flags]: deny | allow file
chmod [options] A-owner@, group@, everyone@:access-permissions /...[:inheritance-flags]:deny | allow file ...
chmod [options] A[index]- file
非簡易 ACL を設定する構文
chmod [options] A[index]{+|=}user|group:name:access-permissions /...[:inheritance-flags]:deny | allow file
chmod [options] A-user|group:name:access-permissions /...[:inheritance-flags]:deny | allow file ...
chmod [options] A[index]- file
簡易 ACL 構文の ACL-entry-type を指定します。ACL エントリタイプについては、表 8–1 を参照してください。
明示的な ACL 構文の ACL-entry-type を指定します。ユーザーとグループの ACL-entry-type には、ACL-entry-ID と、username または groupname も含める必要があります。ACL エントリタイプについては、表 8–1 を参照してください。
許可または拒否するアクセス権を指定します。ACL アクセス特権については、表 8–2 を参照してください。
ACL 継承フラグのオプションリストを指定します。ACL 継承フラグについては、表 8–3 を参照してください。
そのアクセス権を許可するかまたは拒否するかを指定します。
次の例では、ACL-entry-ID の値は関係ありません。
group@:write_data/append_data/execute:deny |
次の例では、ACL-entry-ID が含まれています。特定のユーザー (ACL-entry-type) を ACL に含めるためです。
0:user:gozer:list_directory/read_data/execute:allow |
ACL エントリが表示されるときは、次のようになります。
2:group@:write_data/append_data/execute:deny |
この例の 2 は index-ID 指定と呼ばれますが、これにより、所有者、特定の UID、グループ、および全員用として複数のエントリを含む可能性のある比較的大きな ACL 内の ACL エントリが識別されます。chmod コマンドと一緒に index-ID を指定すれば、ACL のどの部分を変更するかを指定できます。たとえば次のように、chmod コマンドの構文で A3 と指定して、インデックス ID 3 を特定することができます。
chmod A3=user:venkman:read_acl:allow filename |
ACL エントリタイプは、所有者やグループなどの ACL 表現です。次の表の説明を参照してください。
表 8–1 ACL エントリタイプ
ACL エントリタイプ |
説明 |
---|---|
owner@ |
オブジェクトの所有者に許可するアクセス権を指定します。 |
group@ |
オブジェクトを所有するグループに許可するアクセス権を指定します。 |
everyone@ |
ほかのどの ACL エントリにも一致しないすべてのユーザーまたはグループに許可するアクセス権を指定します。 |
user |
ユーザー名を使って、オブジェクトに追加するユーザーに許可するアクセス権を指定します。このエントリには ACL-entry-ID を含める必要があります。username または userID を指定します。値が有効な数値 UID または username でない場合、その ACL エントリタイプは無効です。 |
group |
グループ名を使って、オブジェクトに追加するグループに許可するアクセス権を指定します。このエントリには ACL-entry-ID を含める必要があります。groupname または groupID を指定します。値が有効な数値 GID または groupname でない場合、その ACL エントリタイプは無効です。 |
表 8–2 ACL アクセス特権
アクセス特権 |
アクセス特権のコンパクト表現 |
説明 |
---|---|---|
add_file |
w |
ディレクトリに新しいファイルを追加するためのアクセス権。 |
add_subdirectory |
p |
ディレクトリ上でサブディレクトリを作成するためのアクセス権。 |
append_data |
p |
プレースホルダー。現時点では実装されていません。 |
delete |
d |
ファイルを削除するためのアクセス権。 |
delete_child |
D |
ディレクトリ内のファイルまたはディレクトリを削除するためのアクセス権。 |
execute |
x |
ファイルを実行するためのアクセス権またはディレクトリの内容を検索するためのアクセス権。 |
list_directory |
r |
ディレクトリの内容を表示するためのアクセス権。 |
read_acl |
c |
ACL (ls) を読み取るためのアクセス権。 |
read_attributes |
a |
ファイルの基本属性 (ACL 以外) を読み取るためのアクセス権。基本属性は、stat レベルの属性と考えてください。このアクセスマスクビットを許可したエンティティーは、ls(1) および stat(2) を実行できる状態になります。 |
read_data |
r |
ファイルの内容を読み取るためのアクセス権。 |
read_xattr |
R |
ファイルの拡張属性を読み取るためのアクセス権。または、ファイルの拡張属性ディレクトリの検索を実行するためのアクセス権。 |
synchronize |
s |
プレースホルダー。現時点では実装されていません。 |
write_xattr |
W |
拡張属性を作成するためのアクセス権。または、拡張属性ディレクトリに書き込みむためのアクセス権。 このアクセス権を許可したユーザーは、ファイルの拡張属性ディレクトリを作成できます。属性ファイルのアクセス権を使って、その属性にユーザーがアクセスできるかどうかを制御します。 |
write_data |
w |
ファイルの内容を変更または置き換えるためのアクセス権。 |
write_attributes |
A |
ファイルまたはディレクトリに関連付けられたタイムスタンプを任意の値に変更する権限。 |
write_acl |
C |
ACL の書き込みを行うアクセス権、または chmod コマンドを使って ACL を変更するアクセス権。 |
write_owner |
o |
ファイルの所有者またはグループを変更するためのアクセス権。つまり、ファイルに対して chown または chgrp コマンドを実行することができます。 ファイルの所有権を取得するためのアクセス権。または、ファイルのグループ所有権をユーザーが所属するグループに変更するためのアクセス権。ファイルまたはグループの所有権を任意のユーザーまたはグループに変更する場合は、PRIV_FILE_CHOWN 権限が必要です。 |
ACL 継承を使用する目的は、親ディレクトリの既存のアクセス権を考慮しながら、意図した ACL を新しく作成するファイルまたはディレクトリが継承できるようにすることです。
デフォルトでは、ACL は伝達されません。ディレクトリに非簡易 ACL を設定した場合でも、その ACL はそれ以降に作成されるディレクトリには継承されません。ACL を継承する場合は、ファイルまたはディレクトリにそのことを 指定する必要があります。
表 8–3 ACL 継承フラグ
継承フラグ |
継承フラグのコンパクト表現 |
説明 |
---|---|---|
file_inherit |
f |
親ディレクトリから ACL を継承しますが、適用対象はそのディレクトリのファイルのみとなります。 |
dir_inherit |
d |
親ディレクトリから ACL を継承しますが、適用対象はそのディレクトリのサブディレクトリのみとなります。 |
inherit_only |
i |
親ディレクトリから ACL を継承しますが、新しく作成したファイルまたはサブディレクトリにのみ適用され、そのディレクトリ自体には適用されません。このフラグを使用する場合は、何を継承するかを指定するために、file_inherit フラグまたは dir_inherit フラグ、あるいはその両方を指定する必要があります。 |
no_propagate |
n |
親ディレクトリの ACL をそのディレクトリの第 1 レベルの内容にのみ継承します。第 2 レベル以降の内容には継承しません。このフラグを使用する場合は、何を継承するかを指定するために、file_inherit フラグまたは dir_inherit フラグ、あるいはその両方を指定する必要があります。 |
- |
なし |
アクセス権は付与されていません。 |
また、aclinherit ファイルシステムプロパティーを使用して、デフォルトの ACL 継承ポリシーをファイルシステムに設定することもできます。ポリシーの厳密度はプロパティーによって異なります。詳細については、次の節を参照してください。
ZFS ファイルシステムには、ACL に関連するプロパティーが 2 つ用意されています。
aclinherit – このプロパティーを使って、ACL 継承の動作を決定します。次の値を使用できます。
discard – 新しいオブジェクトの場合に、ファイルまたはディレクトリを作成するときに ACL エントリは継承されません。新しいファイルまたはディレクトリの ACL は、そのファイルまたはディレクトリのアクセス権と等価です。
noallow – 新しいオブジェクトの場合に、継承可能な ACL エントリのうち、アクセスタイプが deny のエントリだけが継承されます。
restricted – 新しいオブジェクトの場合に、ACL エントリが継承されるときに、write_owner および write_acl アクセス権が取り除かれます。
passthrough – プロパティーの値が passthrough に設定されている場合、作成されるファイルのアクセス権は継承可能な ACE によって決定されます。アクセス権に影響を与える継承可能な ACE が存在しない場合、アクセス権はアプリケーションから要求されたアクセス権に従って設定されます。
passthrough-x - このプロパティー値のセマンティクスは次の点を除き passthrough と同じです。passthrough-x を有効にした場合、ファイル作成モードおよびそのモードに影響を与える継承可能な ACE で実行権が設定されている場合に限り、ファイルが実行 (x) 権付きで作成されます。
aclinherit プロパティーのデフォルト値は、restricted です。
aclmode – このプロパティーを指定すると、ファイルが最初に作成されるとき、または chmod コマンドを使ってファイルまたはディレクトリのアクセス権が変更されるときに、ACL の動作が変更されます。次の値を使用できます。
discard – ファイルまたはディレクトリのモードを定義するために必要なエントリを除いて、すべての ACL エントリが取り除かれます。
groupmask – ユーザーまたはグループの ACL アクセス権の強度が、グループのアクセス権より弱くなるように変更されます。ただし、そのファイルまたはディレクトリの所有者と同じ UID を持つユーザーエントリは変更されません。さらに、その ACL アクセス権の強度が、所有者のアクセス権より弱くなるように変更されます。
passthrough – owner@、group@、または everyone@ 以外の ACE は、chmod 操作時に変更されることはありません。owner@、group@、または everyone@ の ACE は無効になり、chmod 操作で要求されたファイルモードが設定されます。
aclmode プロパティーのデフォルト値は、groupmask です。