状況によっては、アクセスパーミッションの仕組みでは制限が大きすぎることがあります。そのため Linux には、特定の処理に対して現在のユーザやグループを一時的に変更することのできる機能が用意されています。たとえば passwd プログラムは /etc/passwd ファイルにアクセスすることから、通常であれば root の権限が必要となります。ただし、このファイルには各ユーザのホームディレクトリのほか、ユーザやグループの ID などの重要な情報が含まれています。このような構造から、一般ユーザに passwd ファイルへの書き込み許可を与えてしまうと、自分以外の情報も変更できてしまいますので、実質的には管理者権限を与えるのと同じになってしまい、セキュリティの意味がなくなってしまいます。このような状況下でも、自分自身のパスワードだけを書き換えることができるようにする必要があることから、 setuid という仕組みが考えられました。 setuid (set user ID) は特殊なファイル属性で、そのファイルの所有者に成り代わってプログラムを実行することができます。たとえば passwd コマンドは下記のようになっています:

-rwsr-xr-x  1 root shadow 80036 2004-10-02 11:08 /usr/bin/passwd

ユーザパーミッションの欄に s が書かれていることで、 setuid ビットが設定されていることが分かります。 setuid ビットの意味により、 passwd コマンドは root の権限下で動作することになります。

setuid ビットはユーザに対して適用される仕組みです。それと同様に、グループに対する仕組みも用意されています。これを setgid ビットと呼びます。このビットが設定されたプログラムは、どのユーザから実行された場合であっても、そのプログラムに設定されたグループ ID で実行されることになります。 setgid ビットが設定されたディレクトリ内では、新しく作成されたファイルやサブディレクトリは、そのディレクトリに対して設定されているグループに割り当てられます。たとえば下記のようなディレクトリが存在するものとします:

drwxrws--- 2 tux archive 48 Nov 19 17:12  backup

グループパーミッションの欄に s が書かれていることで、 setgid ビットが設定されていることが分かります。このディレクトリの所有者と archive グループのメンバーは、パーミッションに書かれているとおり、このディレクトリにアクセスすることができます。このグループのメンバーではないユーザは、対応するグループに 「マッピング」 されます。さらに、書き込まれた全てのファイルの実効グループ ID は archive に設定されます。たとえば、グループ ID archive で実行されたバックアッププログラムは、 root の権限を取得することなく、このディレクトリにアクセスすることができます。

このほか、 sticky ビット と呼ばれる仕組みも用意されています。これは実行可能なプログラムに対して設定されているのか、もしくはディレクトリに対して設定されているのかによって、異なる意味を持ちます。プログラムに対して設定されている場合、このプログラムはメモリに読み込まれ、使用されるごとにハードディスクから読み込む処理を行わなくなります。新しいハードウエアであれば、ハードディスクも十分に高速なものであることから、この仕組みはあまり使用されていません。ディレクトリに対して設定されている場合は、異なるユーザが作成したファイルを削除できないようにするフラグとして動作します。一般的には /tmp や /var/tmp ディレクトリに設定します:

drwxrwxrwt 2 root root 1160 2002-11-19 17:15 /tmp

図19.1「最小 ACL: ACL エントリと許可ビットとの比較」 と 図19.2「拡張 ACL: ACL エントリと許可ビットとの比較」 には、最小 ACL と拡張 ACL の例を示しています。この図は 3 つのブロックから構成され、左から順に 「ACL エントリの種類指定」, 「ACL の例」, 「対応する従来型のパーミッションビット」 (たとえば ls -l で表示されるもの) をそれぞれ示しています。いずれの場合であっても、 所有者クラス のビットは ACL の所有者エントリに紐づけられ、 その他のクラス はその他の種類のエントリに紐づけられます。ただし、 グループクラス の部分については、この 2 つの例で対応付けが異なることに注意してください。

図 19.1: 最小 ACL: ACL エントリと許可ビットとの比較 #

最小 ACL の (マスクエントリがない) 場合、グループクラスのパーミッションは、 図19.1「最小 ACL: ACL エントリと許可ビットとの比較」 に示されているとおり、そのまま ACL の所有グループのエントリに対応します。拡張 ACL の (マスクエントリがある) 場合は、 図19.2「拡張 ACL: ACL エントリと許可ビットとの比較」 に示されているとおり、グループクラスのパーミッションはマスクエントリに対応することになります。

図 19.2: 拡張 ACL: ACL エントリと許可ビットとの比較 #

このようなマッピングの仕組みが存在することで、アプリケーション側が ACL に対応していない場合でも、問題なく動作できるようになっています。つまり、 ACL は従来のパーミッションビットに対する 「微調整」 として働くことになります。なお、パーミッションビット側を変更することで ACL 側も反映されますし、逆に ACL を変更することでパーミッションビット側にも反映されます。

コマンドラインで getfacl と setfacl の各ツールを使用することで、 ACL を参照したり制御したりすることができるようになります。本章では、これらのコマンドの使用方法について説明しています。

まずはディレクトリを作成する前に、 umask コマンドを利用してファイルオブジェクトの作成時におけるパーミッションのマスク値を設定してください。 umask 027 のように実行することで、所有者には全ての許可を ( 0 ) 、グループに対しては書き込みビットを禁止し ( 2 ) 、その他に対しては全てを禁止する ( 7 ) ように設定します。 umask では、パーミッションのビットのうち、マスク (無効化) したいビットを 1 にします。詳しくは 11.4項 「既定の umask」 もしくは umask のマニュアルページをお読みください。

次に mkdir mydir を実行して、 mydir ディレクトリを umask で設定したパーミッションビットで作成します。作成したディレクトリに対して ls -dl mydir のように実行し、まずはどのようなパーミッションが設定されているのかを確認します。このコマンドの出力は、たとえば下記のようになっているはずです:

drwxr-x--- ... tux project3 ... mydir

次に getfacl mydir を実行して、 ACL の初期状態を確認します。出力は下記のようになっているはずです:

# file: mydir
# owner: tux
# group: project3
user::rwx
group::r-x
other::---

最初の 3 行には、ディレクトリの名前と所有者、および所有グループに関する情報が表示されています。次の 3 行には、それぞれ所有者と所有グループ、そしてその他に対する ACL エントリが表示されています。この時点では最小 ACL であることから、 getfacl の出力で得られる情報と ls で得られる情報は、書式は違うものの違いがありません。

次に、 geeko というユーザと mascots というグループに対して、読み込み／書き込み／実行の各許可を設定します:

# setfacl -m user:geeko:rwx,group:mascots:rwx mydir

setfacl コマンドで -m を指定することで、既存の ACL を修正しています。その後ろのパラメータは修正すべき ACL エントリを表していて、エントリ同士の間はカンマ区切りで指定しています。最後のパラメータは ACL の修正を適用したい先の名前 (ここではディレクトリ) を指定しています。上記のように実行したあとは、 getfacl コマンドで再度 ACL を表示してみてください。

# file: mydir
# owner: tux
# group: project3
user::rwx
user:geeko:rwx
group::r-x
group:mascots:rwx
mask::rwx
other::---

すると、ユーザ geeko およびグループ mascots に対するエントリと、マスクエントリがそれぞれ追加されていることが分かります。マスクエントリでは、全てのアクセス許可がそのまま動作するように、全ての許可が指定されています。 setfacl では、 -n を指定しない限り、マスクエントリを自動調整する処理を行います。マスクエントリは特定ユーザや特定グループ、そして、所有グループに対する最大限の許可を指定する項目です。ここで再度 ls -dl mydir を実行してみます。すると、 mask の設定に対応してパーミッションが表示されるようになります。

drwxrwx---+ ... tux project3 ... mydir

行頭には従来型のパーミッションビットが表示されていますが、ここに + という表示が追加されているのが分かります。これにより、この項目に対して 拡張 ACL が存在していることを表しています。

ls の出力にもあるとおり、マスクエントリの許可には書き込み許可が含まれています。従来型のパーミッションの仕組みでは、このビットが設定されていれば、所有グループ (上記の例では project3 ) が、そのディレクトリ (上記の例では mydir) に対して書き込み権限があることを表していました。

しかしながら、所有グループに対する実際の許可は、所有グループに対するアクセス許可とマスクエントリの許可に従って動作することになります。この例では r-x が適用されます (表19.2「アクセス許可のマスク」 をお読みください) 。そのため、この例における所有グループに対する実際の許可については、 ACL を追加したあとも特に変わっていないことになります。

さらに setfacl や chmod でマスクエントリを編集します。たとえば chmod g-w mydir のように実行します。こちらを実行後、 ls -dl mydir を実行すると、下記のような表示になります:

drwxr-x---+ ... tux project3 ... mydir

getfacl mydir の出力は下記のようになります:

# file: mydir
# owner: tux
# group: project3
user::rwx
user:geeko:rwx          # effective: r-x
group::r-x
group:mascots:rwx       # effective: r-x
mask::r-x
other::---

chmod を実行してグループクラスのビットから書き込み権限を取り除くと、 ls の出力でマスクビットが適切に変更されていることがわかるようになります。これにより、書き込み権限は mydir の所有者に限定されることになります。 getfacl でも同じ内容を確認することができます。出力には上記のようなコメント部分 (#) が含まれるようになり、マスクエントリによって実際に作用するアクセス許可と元々のアクセス許可に差異があることを示すようになります。元のアクセス許可に戻したい場合は、 chmod g+w mydir を実行してください。

ディレクトリには既定の ACL を設定することができます。既定の ACL は特殊な ACL で、ディレクトリ内に作成されたオブジェクト (サブディレクトリやファイル) に対して適用される、既定のアクセス権として動作します。

ACL で保護されたファイルシステムオブジェクトに対して、プロセスやアプリケーションがアクセスを行う場合、事前にチェックアルゴリズムが適用されます。基本的な考え方としては、所有者エントリ, 特定ユーザエントリ, 所有グループエントリ, 特定グループエントリ, その他の順で確認が行われます。アクセスは、そのプロセスに最も適したエントリに従って処理されます。また、権限では複数のエントリを合成して判断するようなことはおこないません。

プロセスが複数のグループに属していて、複数のグループエントリに該当するような場合は、さらに複雑な処理になります。この場合は、該当する複数のエントリの中からランダムにエントリが選択され、必要なアクセス許可を得ることになります。この処理は、どのエントリが最終的に 「アクセスを許可する」 という結果を引き出すのかはわかりません。同様に、該当する複数のエントリグループの中のどれであってもアクセスが許可されない場合、ランダムに選択されたエントリから、最終結果である 「アクセス拒否」 が発行されます。