ACL を使用した Sun QFS および SAM-QFS ファイルの保護

以前のバージョンの Oracle Solaris は、主に POSIX ドラフト ACL 仕様に基づく ACL 実装をサポートしていました。POSIX ドラフトに基づく ACL は、UFS ファイルを保護するために使用され、NFSv4 より前のバージョンの NFS によって変換されます。

NFSv4 の導入により、新しい Oracle Solaris ACL モデルは、NFSv4 が提供する UNIX クライアントと UNIX 以外のクライアントとの間の相互運用性を完全にサポートしています。NFSv4 仕様で定義されている新しい ACL 実装は、NT 方式の ACL に基づくより豊かなセマンティクスを提供します。

新しい ACL モデルの主な相違点は、次のとおりです。

NFSv4 仕様に基づいており、NT 方式の ACL に似ています。
より詳細なアクセス権限のセットを提供します。詳細は、表 8-3 を参照してください。
setfacl および getfacl コマンドではなく、chmod および ls コマンドを使って設定および表示します。
アクセス権限がどのように適用されるかを設計するための、より豊富な継承セマンティクスを提供します。詳細は、「ACL 継承」を参照してください。

どちらの ACL モデルも、標準のファイルアクセス許可よりも詳細なアクセス制御が可能です。POSIX ドラフトの ACL と同様に、新しい ACL は複数のアクセス制御エントリ (ACE) で構成されます。

POSIX ドラフトスタイルの ACL は、単一のエントリを使用して、許可する権限と拒否する権限を定義します。新しい ACL モデルには、アクセスチェックに影響する ALLOW と DENY という 2 種類の ACE があります。このため、権限を定義する 1 つの ACE から、その ACE に定義されていない権限が許可されているか拒否されているかを推論することはできません。

新しい Oracle Solaris ACL モデルの詳細については、『Oracle Solaris Administration: ZFS File Systems』の「New Solaris ACL Model」を参照してください。

SAM-QFS でのユーザーおよびグループアイデンティティーのマッピング

現在のところ、SAM-QFS は短期的 ID または SID をサポートしていません。したがって、すべての Windows アイデンティティーは、idmap サービスを使用して明示的に定義するか、Active Directory サービスから提供する必要があります。明示的マッピングが定義されていない、SMB サーバーで出現するアイデンティティーは、自動的にデフォルトの nobody アイデンティティーに設定されます。

アイデンティティーマッピング管理の詳細については、『Oracle Solaris Administration: SMB and Windows Interoperability』の第 2 章「Identity Mapping Administration (Tasks)」を参照してください。

NFSv4 ACL をサポートするためのファイルシステムの作成と変換

POSIX ACL は、SAM-QFS ファイルシステムに存在するデフォルトの ACL です。SMB サービスをサポートするためには、SAM-QFS ファイルシステムが NFSv4 ACL もサポートする必要があります。

sammkfs -A コマンドを使用して、NFSv4 ACL でファイルシステムを作成します。たとえば、ファイルシステム sqfs1 を NFSv4 ACL で作成するには:
```
# sammkfs -A -S sqfs1
```
sammkfs コマンドの -A オプションの詳細については、『Sun QFS and Sun Storage Archive Manager 5.3 Reference Manual』の「sammkfs(1M)」を参照してください。
samfsck -A コマンドを使用して、既存の POSIX ACL を NFSv4 ACL に変換します。たとえば、既存のファイルシステム sqfs2 上で POSIX ACL から NFSv4 ACL に変換するには:
```
# samfsck -F -A sqfs2 
```
注 - POSIX ACLS から NFSv4 への変換は予約できません。変換はファイルシステムのバージョン V2 または V2A だけに適用されます。

samfsck コマンドの -A オプションの詳細については、『Sun QFS and Sun Storage Archive Manager 5.3 Reference Manual』の「samfsck(1M)」を参照してください。

ACL を設定する構文の説明

次のように、2 つの基本的な ACL の形式が用意されています。

簡易 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

owner@、group@、everyone@: 簡易 ACL 構文の ACL-entry-type を指定します。ACL-entry-types については、表 8-2 を参照してください。
user または group:ACL-entry-ID=username または groupname: 明示的な ACL 構文の ACL-entry-type を指定します。ユーザーとグループの ACL-entry-type には、ACL-entry-ID、username、または groupname も含める必要があります。ACL-entry-types については、表 8-2 を参照してください。
access-permissions/.../: 許可または拒否するアクセス権を指定します。ACL アクセス権限については、表 8-3 を参照してください。
inheritance-flags: ACL 継承フラグのオプションリストを指定します。ACL 継承フラグについては、表 8-4 を参照してください。
deny | allow: アクセス権を許可するか拒否するかを指定します。

次の例では、ACL-entry-ID の値は関係ありません。

group@:write_data/append_data/execute:deny

特定のユーザー (ACL-entry-type) を ACL に含めるため、次の例には ACL-entry-ID が含まれています。

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-2 ACL エントリタイプ

ACL エントリタイプ	説明
`owner@`	オブジェクトの所有者に許可するアクセス権を指定します。
`group@`	オブジェクトの所有グループに許可するアクセス権を指定します。
`everyone@`	ほかのどの ACL エントリにも一致しないすべてのユーザーまたはグループに許可するアクセス権を指定します。
`user`	ユーザー名を使って、オブジェクトの追加ユーザーに許可するアクセス権を指定します。ACL-entry-ID を含める必要があり、これには `username` または `user-ID` が含まれます。値が有効な数値 UID または `username` でない場合、ACL エントリタイプは無効です。
`group`	グループ名を使って、オブジェクトの追加グループに許可するアクセス権を指定します。ACL-entry-ID を含める必要があり、これには `groupname` または `group-ID` が含まれます。値が有効な数値 GID または `groupname` でない場合、ACL エントリタイプは無効です。

ACL アクセス権限について、次の表で説明します。

表 8-3 ACL アクセス権限

アクセス権限	説明
`add_file`	新しいファイルをディレクトリに追加するための権限。
`add_subdirectory`	ディレクトリ上でサブディレクトリを作成するための権限。
`delete`	ファイルを削除するための権限。
`delete_child`	ディレクトリ内のファイルまたはディレクトリを削除するための権限。
`execute`	ファイルの実行またはディレクトリの内容の検索を行うための権限。
`list_directory`	ディレクトリの内容を一覧表示するための権限。
`read_acl`	ACL を読み取るための権限 (`ls`)。
`read_attributes`	ファイルの基本属性 (ACL 以外) を読み取るための権限。(基本属性は stat レベルの属性と考えてください)。このアクセスマスクビットを許可することは、エンティティーが `ls`(1) および `stat`(2) を実行できることを意味します。
`read_data`	ファイルの内容を読み取るための権限。
`read_xattr`	ファイルの拡張属性を読み取るための権限、またはファイルの拡張属性ディレクトリの検索を実行するための権限。
`write_xattr`	拡張属性を作成するための権限、または拡張属性ディレクトリに書き込むための権限。この権限をユーザーに許可することは、ユーザーがファイルの拡張属性ディレクトリを作成できることを意味します。属性ファイルの権限は、属性へのユーザーのアクセスを制御します。
`write_data`	ファイルの内容を変更または置き換えるための権限。
`write_attributes`	ファイルまたはディレクトリに関連付けられた時間を任意の値に変更する権限。
`write_acl`	ACL を書き込むための権限、または `chmod` コマンドを使って ACL を変更するための権限。
`write_owner`	ファイルの所有者またはグループを変更するための権限、つまり、ファイルに対して `chown` または `chgrp` コマンドを実行できる権限。ファイルの所有権を取得するための権限、または、ファイルのグループ所有権をユーザーがメンバーであるグループに変更するための権限。ファイルまたはグループの所有権を任意のユーザーまたはグループに変更する場合は、`PRIV_FILE_CHOWN` 権限が必要です。

例 8-3 SAM-QFS ファイルの簡易 ACL の変更

次の例では、簡易 ACL が file.1 に存在します。

# ls -v file.1
-rw-r--r--   1 root     root      206674 Jun 14 10:54 file.1
     0:owner@:read_data/write_data/append_data/read_xattr/write_xattr
         /read_attributes/write_attributes/read_acl/write_acl/write_owner
         /synchronize:allow
     1:group@:read_data/read_xattr/read_attributes/read_acl/synchronize:allow
     2:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow

ACL 継承

ACL 継承を使用する目的は、親ディレクトリの既存の権限ビットを無視することなく、新しく作成したファイルまたはディレクトリが適切な ACL を継承できるようにすることです。

デフォルトでは、ACL は伝達されません。ディレクトリに非簡易 ACL を設定した場合、これはそれ以降のディレクトリには継承されません。ファイルまたはディレクトリに ACL の継承を指定する必要があります。

オプションの継承フラグについて、次の表で説明します。

表 8-4 ACL 継承フラグ

継承フラグ	説明
`file_inherit`	ACL の継承を親ディレクトリからそのディレクトリのファイルだけにします。
`dir_inherit`	ACL の継承を親ディレクトリからそのディレクトリのサブディレクトリだけにします。
`inherit_only`	親ディレクタから ACL を継承します。このオプションは、新しく作成したファイルまたはサブディレクトリだけに適用され、ディレクトリ自体には適用されません。何を継承するかを指定するために、このフラグには `file_inherit` フラグ、`dir_inherit` フラグ、またはその両方が必要です。
`no_propagate`	ACL を、親ディレクトリから、そのディレクトリの第 1 レベルの内容にのみ継承し、第 2 レベル以降の内容には継承しません。何を継承するかを指定するために、このフラグには `file_inherit` フラグ、`dir_inherit` フラグ、またはその両方が必要です。

デフォルトでは、ACL はディレクトリ構造を通じて伝達されません。

例 8-4 デフォルト ACL 継承の許可

次の例では、test.dir のユーザー gozer に対し、read_data/write_data/execute の非簡易 ACE が適用されます。

# chmod A+user:gozer:read_data/write_data/execute:allow test.dir
# ls -dv test.dir
drwxr-xr-x+  2 root     root           2 Jun 15 10:40 test.dir
     0:user:gozer:list_directory/read_data/add_file/write_data/execute:allow
     1:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/read_xattr/write_xattr/execute/read_attributes
         /write_attributes/read_acl/write_acl/write_owner/synchronize:allow
     2:group@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow
     3:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

test.dir サブディレクトリが作成された場合、ユーザー gozer の ACE は伝達されません。ユーザー gozer は、sub.dir に対する権限によりファイル所有者、グループメンバー、または everyone@ としてのアクセスが許可されている場合は、sub.dir だけにアクセスできます。

# mkdir test.dir/sub.dir
# ls -dv test.dir/sub.dir
drwxr-xr-x   2 root     root           2 Jun 15 10:41 test.dir/sub.dir
     0:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/read_xattr/write_xattr/execute/read_attributes
         /write_attributes/read_acl/write_acl/write_owner/synchronize:allow
     1:group@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow
     2:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

例 8-5 ディレクトリ内のファイルに対する ACL 継承の許可

次の例では、ディレクトリ内の新しく作成されたすべてのファイルにいくつかの権限が適用されますが、それらの権限はディレクトリ自体には適用されません。file_inherit フラグは権限がファイルに対するものであることを示し、inherit_only フラグは権限が継承に対するものであり、ディレクトリ自体には適用されないことを示します。

# chmod A+user:bob:read_data/execute:file_inherit/inherit_only:deny mydir
# ls -vd mydir
dr-xr-xr-x+     2     root     root        4096 Jul 5 19:10 mydir 
   0:user:bob:list_directory/read_data/execute:file_inherit/inherit_only:deny
   1:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
      /append_data/read_xattr/write_xattr/execute/delete_child
      /read_attributes/write_attributes/read_acl/write_acl/write_owner
      /synchronize:allow
   2:group@:list_directory/read_data/read_xattr/execute/read_attributes
      /read_acl/synchronize:allow
   3:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
      /read_acl/synchronize:allow

myfile ファイルが mydir ディレクトリ内に作成された場合、myfile ファイルは自動的にすべてのアクセス権を継承します。

# cd mydir
# touch myfile
# ls -v myfile
-r--r--r--+     1     root     root        0 Jul 5 19:11 myfile

   0:user:bob:read_data/execute:file_inherit/inherit_only:deny
   1:owner@:read_data/write_data/append_data/read_xattr/write_xattr
      /read_attributes/write_attributes/read_acl/write_acl/write_owner
      /synchronize:allow
   2:group@:read_data/read_xattr/read_attributes/read_acl/synchronize:allow
   3:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize:allow

ナビゲーションリンクをスキップ
印刷ビューの終了
	Sun QFS File System 5.3 構成および管理ガイド Sun QFS and Sun Storage Archive Manager 5.3 Information Library (日本語)