netatalk

netatalk.io

ACL のサポート

Netatalk は、サポートされているサーバーのファイルシステム上の ACL を AFP ACL および 有効な AFP パーミションにマッピングする。すべてのサーバープラットフォームに対して ACL の実装を提供したり、ACL がホストのファイルシステムのアクセスチェックを上書きすることはない。

サポートマトリックス

| Server platform and ACL backend | Support | AFP behavior | | — | — | — | | Solaris/illumos with NFSv4/ZFS ACLs | Supported | Maps NFSv4 ACEs to and from the AFP/macOS ACL format. | | FreeBSD with libsunacl/ZFS ACLs | Supported | Uses the NFSv4/ZFS ACL implementation. | | Linux with POSIX 1e ACLs | Supported | Maps the less expressive POSIX ACL model to AFP; see POSIX ACLs. | | macOS (Darwin) host ACLs | Not supported | Disabled at the build system level. | | macOS AFP client | Supported | Can use the ACL facilities of a supported server backend. |

互換性のある POSIX ACL API が見つかった場合、他のプラットフォームでもコンパイルできるが、ドキュメント化されたサポートマトリックスには含まれない。

Netatalk の ACL の使用方法

認証後、afpd はユーザーの有効なファイルシステム ACL 権限を計算し、それを AFP UARights にマッピングする。Finder は UARights を使用して、どの操作を提供するかを決定する。例えば、制限付きモードビットを持つディレクトリであっても、ACL がユーザーに書き込みアクセスを許可している場合、そのユーザーに対して書き込み可能として表示される。ホストファイルシステムは、操作自体の権限の権威であり続ける。

map acls オプションは、このクライアント向けのマッピングを制御する：

ACL の有効な権限のマッピングには、LDAP、Active Directory、またはその他のディレクトリサービスは必要ない。認証されたユーザーのローカル UNIX ID とサーバーファイルシステムの ACL を使用する。

AFP ACL エントリーは UUID によってユーザーとグループを識別するが、サポートされているサーバー ACL バックエンドは UID または GID によって名前付きエントリーを識別する。ACL エントリーを返すまたは受け入れる際、Netatalk はサーバーの通常のユーザー/グループ検索を通じて UID または GID を解決し、結果として得られた名前を UUID に変換する。LDAP が構成されていない場合、ローカル UID または GID から可逆的な Netatalk ローカル UUID を生成できる。これはサーバー側のマッピングには十分であるが、Netatalk はボリュームをネットワーク ID をサポートしていないと広告するため、macOS クライアントは AFP ACL エントリーの表示および編集機能を使用しない。

これらのクライアント向け ACL 機能を有効にするには、Netatalk のACL処理のためのオプションを、関連する各ユーザーおよびグループ名を安定した UUID にマッピングできるディレクトリで構成する。LDAP は、この検索のために Netatalk が実装するメカニズムである。Active Directory および Open Directory は例であり、要件ではない。ユーザーおよびグループの UUID 属性を持つ LDAP ディレクトリを代わりに使用できる。実際には、ディレクトリはサーバーとクライアントで共有されるべきであり、UUID が同じ ID を参照するようにする必要がある。

Solaris/ZFS ボリュームでは、ACL の継承と保持に適した ZFS プロパティを構成する：

aclinherit = passthrough
aclmode = passthrough

これらの設定の意味については、ホストの zfs(8) ドキュメントを参照する。

macOS の ACL

AFP は、macOS/Darwin モデルを使用して ACL を表現する：UUID で識別されたユーザーとグループに対して、細かく権限を許可または拒否する ACE の順序付きリストである。ディレクトリの権限は区別される。例えば、ファイルの追加とサブディレクトリの追加は別々の権限である。

Netatalk は、afpd が macOS 上で実行される場合、ネイティブの macOS (Darwin) ACL を意図的にサポートしない。そのプラットフォームではビルド時に ACL サポートが無効化される。POSIX ACL 実装は、Darwin の順序付きの許可/拒否および細かいディレクトリのセマンティクスを安全に評価または保持することができない。

これは AFP クライアントの制限ではなく、サーバーホストの制限である。macOS クライアントは、Linux POSIX-ACL または Solaris/FreeBSD ZFS-ACL サーバーの ACL サポートを使用できる。

ZFS の ACL

Netatalk は、Solaris/illumos 上では NFSv4 ACL API を、FreeBSD 上では libsunacl API を使用する。これらの ACL は AFP/macOS ACL モデルに十分近く、許可/拒否 ACE を保持し、POSIX ACL マッピングよりも多くのディレクトリおよび継承のセマンティクスを保持できる。

POSIX の ACL

Linux バックエンドは、POSIX 1003.1e ACL API を使用する。これは AFP/macOS または NFSv4 ACL とは異なる、表現力の低いモデルであるため、Netatalk は AFP クライアントと交換される ACL エントリーを必然的に近似する。

すべてのオブジェクトに対して、Netatalk は POSIX アクセス ACL を読み取る。ディレクトリの場合、AFP ACL を返す際にデフォルト ACL も読み取る。POSIX モデルは 2 つの ACL タイプを定義する：ファイルとディレクトリはアクセスチェックのために参照されるアクセス ACL を持つことができる。ディレクトリはまた、アクセスチェックでは使用されないデフォルト ACL を持つことができる。デフォルト ACL を持つディレクトリ内に新しいオブジェクトが作成されると、デフォルト ACL が新しいオブジェクトのアクセス ACL として適用される。サブディレクトリは親からデフォルト ACL を継承する。継承制御のさらなるメカニズムはない。

これらの違いが、Netatalk の AFP マッピングの限界を決定する：

POSIX 1003.1e は6つの異なるタイプの ACL エントリーを定義している。前半の3つは標準の UNIX パーミションを統合するのに用いられている。これらは ACL として最小限の形であり、存在することは必須であり、 そして各々のタイプにつきたった一つのエントリーだけが ACL 内に許される。

残りのエントリーのタイプは伝統的パーミションモデルの拡張である：

ACL を意識していないアプリケーションとの互換性を維持のため、POSIX 1003.1e は、オブジェクトの UNIX パーミションを検索したり処理するシステムコールやユーティリティーのセマンティクスを変える。オブジェクトが必要最低限の ACL のみ保持している場合、UNIX パーミションのグループパーミションビットは ACL_GROUP_OBJ エントリーの値に対応する。

しかしながら、もし ACL に ACL_MASK エントリーが含まれている場合、挙動は異なるものとなる。UNIX パーミションのグループパーミションビットは ACL_MASK エントリーの値に対応する、すなわち、chmod g-w の呼び出しは、グループに対する書き込みアクセスを無効にするだけでなく、 ACL_USER ないしは ACL_GROUP エントリーによって許可されていた書き込みアクセスのエンティティ全てを無効にするのである。

POSIX ACL から AFP の ACL へのマッピング

クライアントがオブジェクトの ACL を読み取ると、afpd はその POSIX ACL を AFP の macOS スタイルの ACL 形式にマッピングする。AFP ACL の書き込みは、POSIX ACL エントリーにマッピングされる。これは近似であり、正確な往復ではない。なぜなら、サーバー ACL モデルはすべての AFP ACL 機能を表現できないからである。

POSIX ACL マスクは、別個のクライアントパーミションレイヤーとして公開されない。代わりに、afpd は AFP を通じて報告する有効なユーザーおよびグループの権限を計算する。AFP がオブジェクトの UNIX パーミションを変更すると、afpd は ACL_USER_OBJ、ACL_GROUP_OBJ、および ACL_OTHER を更新する。ACL_MASK エントリーが存在する場合、新しいグループ権限が有効になるようにマスクを再計算し、名前付きの ACL_USER および ACL_GROUP エントリーはそのまま保持される。