第10章 Linux におけるアクセス制御リスト

目次

10.1. 従来のファイルパーミッション
10.2. ACL の利点
10.3. 定義
10.4. ACL の処理
10.5. アプリケーションにおける ACL サポート
10.6. さらなる情報

概要

POSIX ACL (アクセス制御リスト) は、ファイルシステムの要素 (ファイルや ディレクトリなど) に設定する従来のパーミッションを拡張するために利用 することができるものです。 ACL を利用すると、従来のパーミッションよりも より柔軟な構成を取ることができます。

POSIX ACL という用語は正規の POSIX ((Portable Operating System Interface) 内の標準として 定められていたものです。 ACL を規定している POSIX 1003.1e と POSIX 1003.2c の ドラフト標準は諸般の理由により取り消されていますが、 ACL (UNIX 系に属する多くの システムで利用されているもの) はこれらのドラフト標準に従って作られていて、 ファイルシステムの ACL (本章での記述範囲) 実装も、これら 2 つの標準に従って 作られています。

10.1. 従来のファイルパーミッション

従来のファイルパーミッションに関する詳細な情報は、 GNU coreutils の info パッケージ内 File permissions ノードに詳しく 書かれています (info coreutils "File permissions" で表示することができます) 。それらをさらに拡張したものとして、それぞれ setuid, setgid, sticky の各ビットが用意されています。

10.1.1. setuid ビット

特定の状況下において、アクセス許可は過度の制限をもたらしてしまいます。 そのため、 Linux では特定の作業を行なうにあたって、現在のユーザと グループを一時的に変更できる設定が用意されています。たとえば passwd プログラムでは、通常 /etc/passwd にアクセスするため、 root の権限が 必要になります。それは、このファイルにはいくつかの重要な情報、たとえば ユーザのホームディレクトリの情報や、ユーザ/グループの ID などがあります。 そのため、通常のユーザに対しては passwd ファイルの 修正が許可されることはありません。もしも全てのユーザに対して書き込みを 許可してしまうと、情報を自由に書き換えることができてしまい、非常に 危険であるためです。この問題を解決するための方法の 1 つが setuid の仕組みです。 setuid (set user ID; ユーザ ID の設定) ビットは、システムに対して指定したユーザ ID での実行を行なわせる ための特殊なファイル属性で、たとえば passwd コマンドは 下記のような属性になっています:

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

上記の表示のうち s が、 setuid ビットの設定されている 印です。 setuid ビットが設定されていることから、 passwd コマンドを実行する全てのユーザは、そのコマンドを root として実行します。

10.1.2. setgid ビット

setuid ビットはユーザに対して適用されるものですが、グループに対しても同様の ことができます。それが setgid ビットです。このビットが 設定されたプログラムは、どのユーザから起動された場合であっても、そのファイル のグループ ID で動作させたものとして扱われます。そのため、 setgid ビットが 設定されたディレクトリ内で新しくファイルやサブディレクトリを作成すると、 そのディレクトリに設定されたグループに属するものとして作成されます。 たとえば下記のようなディレクトリがあると仮定します:

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

グループパーミッションの欄に s が書かれていて、これによって setgid ビットが設定されていることを表わしています。また、このディレクトリの 所有者と、 archive グループに属する ユーザは、このディレクトリにアクセスすることができます。このグループに属して いないユーザは、関連するグループに マップ されます。この ディレクトリに書き込まれた全てのファイルは、 archive グループが実効グループ ID となります。たとえば archive のグループ ID を持つバックアッププログラムがあったとすると、このプログラムは root の権限無しでこのディレクトリにアクセスできるようになります。

10.1.3. sticky ビット

sticky ビット は、実行可能なプログラムやディレクトリに 設定した場合、それぞれ異なる動作をします。このビットをプログラムに対して 設定すると、そのファイルはハードディスクから毎回読み込まれることがなくなり、 RAM 内に保持されるようになります。この属性は、今となってはハードディスクが 十分に高速化してしまったことから、ほとんど使われることがありません。 このビットをディレクトリに対して設定すると、ユーザ間でお互いのファイルを 削除できないようになります。典型例が /tmp/var/tmp のディレクトリです:

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

10.2. ACL の利点

従来、 Linux システムではそれぞれのファイルオブジェクトに対して 3 種類の パーミッションセットを設定していました。各セットには読み込み (r), 書き込み (w), 実行 (x) の各パーミッションが存在し、それを 3 種類のタイプ、 ファイルの所有者、グループ、その他のユーザに対してそれぞれ設定していました。 これに加えて set user id (setuid), set group id (setgid) , sticky の各ビットが存在していました。このようなシンプルな仕組みは実際の使用形態 でも十分な仕組みでしたが、より複雑なシナリオや高度なアプリケーションの 場合、システム管理者はこのようなシンプルな仕組みをうまく使うため、 数多くの回避策を利用しなければなりませんでした。

ACL は従来のパーミッションに対する拡張として使用することができます。また、 ACL は所有者以外の個別のユーザや、個別のグループであっても設定を行なう ことができます。アクセス制御リストは Linux カーネルに搭載されている機能で、 現時点では ReiserFS, Ext2, Ext3, Ext4, JFS, XFS に対応しています。 ACL を利用することで、アプリケーション側で複雑なアクセス許可モデルを構築 したりすることなく、複雑なシナリオを利用できるようになります。

ACL の利点は、 Windows サーバを Linux サーバで置き換えたいような場合に 明確になります。サーバ側の移行後も、接続されたワークステーションで Windows を利用することが想定されますが、このような場合でも Linux システムは Samba を利用して、 Windows クライアントに対するファイル/印刷サービスの 提供を行ないます。 Samba も ACL に対応しているため、アクセス許可を Windows のグラフィカルユーザインターフェイスから設定 (ただし Windows NT または それ以降のバージョンである必要があります) し、それを Linux サーバ側に保存 することができます。また Samba スイートの一部である winbindd を利用すると、 Windows ドメインにのみ存在し、 Linux サーバ上には存在して いないユーザに対しても、アクセス許可を設定することができます。

10.3. 定義

ユーザクラス

通常のファイルパーミッションでは、ファイルシステム内でパーミッションを 設定する際に、ユーザを 3 種類の クラス に区分して 扱います。それはそれぞれ、所有者とグループ、その他のユーザです。また、 それぞれのユーザクラスに対して、 3 種類のビットでアクセス許可を設定する ことができます。それぞれ読み込み (r), 書き込み (w), 実行 (x) です。

ACL

全ての種類のファイルシステム要素 (ファイルとディレクトリ) に対して、 ユーザとグループに対するアクセス許可を設定するものです。

デフォルト ACL

デフォルト ACL はディレクトリに対してのみ設定するものです。これらは、 そのディレクトリ内に何らかの要素 (ファイルやディレクトリ) が作成された 際に設定される ACL の既定値を設定します。

ACL 項目

それぞれの ACL には ACL 項目のセットが存在しています。 ACL 項目には、 そのタイプとユーザまたはグループ、そしてアクセス許可セットが含まれます。 項目の種類によっては、ユーザまたはグループが未定義になる場合もあります。

10.4. ACL の処理

表10.1「ACL 項目タイプ」 には、 ACL 項目として存在しうる 6 種類の タイプが示されています。それぞれはユーザまたはユーザのグループに対して 許可を設定するものです。ここで 所有者 の項目は、 ファイルやディレクトリの所有者に対する許可を設定します。また、 所有グループ の項目は、ファイルを所有するグループ に対して設定する許可を指します。なお、スーパーユーザであれば chownchgrp コマンドで所有者や 所有グループを変更することができますが、この場合これらの項目は、新しい 所有者や所有グループに対する設定として解釈されるようになります。また、 指名ユーザ の項目は、項目内に書かれたユーザに対して 設定する許可のことを指します。さらに 指名グループ の項目では、同様に項目内に書かれたグループに対して、アクセス許可を設定 するものを指します。なお、指名ユーザと指名グループの項目にのみ、それぞれ ユーザまたはグループ欄に記載があります。最後に その他 の項目には、その他のユーザに対するアクセス許可を設定します。

また、 マスク の項目は、指名ユーザや指名グループ、 所有グループに対して許可の制限をかけることができるもので、許可の項目の うち、どれを有効としてどれをマスクするかを設定します。指名ユーザや指名 グループ、所有グループに対して設定した許可がマスクとしても存在する場合、 その許可は有効なものとして扱われます。逆にマスクとしてしか存在していない 場合や、実際の項目内にしか存在していない項目は、それらは無効なものと なり、許可は取り消されます。ただし、所有者 に 対する許可は常に有効になります。 表10.2「アクセスパーミッションのマスク」 では、例を もとに仕組みを説明しています。

ACL には 2 種類の基本分類があります: 最小 ACL には、 所有者と所有グループ、およびその他のユーザに対する項目だけが含まれていて、 これらはファイルやディレクトリに対して設定する、従来のアクセス許可ビットの 仕組みと同じものです。 拡張 ACL はそこから拡張した もので、マスク項目が含まれていなければならないほか、指名ユーザや指名 グループの種類の項目を含む場合があるものです。

表10.1 ACL 項目タイプ

種類

テキストでの書式

所有者

user::rwx

指名ユーザ

user:name:rwx

所有グループ

group::rwx

指名グループ

group:name:rwx

マスク

mask::rwx

その他

other::rwx


表10.2 アクセスパーミッションのマスク

項目の種類

テキストでの書式

許可

指名ユーザ

user:geeko:r-x

r-x

マスク

mask::rw-

rw-

有効となる許可:

r--


10.4.1. ACL の項目とファイルモードパーミッションビット

図10.1「最小 ACL: パーミッションビットと ACL 項目の比較」図10.2「拡張 ACL: パーミッションビットと ACL 項目の比較」 では、それぞれ最小 ACL と拡張 ACL に関する説明を図示しています。図には 3 つのブロックがあります。左側のブロックでは ACL のタイプ説明を、 中央のブロックでは ACL の例を、右側では対応する従来のファイルパーミッション (たとえば ls -l で表示できるもの) を示しています。いずれの場合とも、 所有者クラス (owner class) のパーミッションは ACL の所有者 (owner) の項目に当てはまるほか、 その他のクラス (other class) のパーミッションは その他 (other) の ACL 項目に当てはまります。ただし、 グループクラス (group class) のパーミッションは、 2 つの場合で 異なっていることに注意してください。

図10.1 最小 ACL: パーミッションビットと ACL 項目の比較

最小 ACL: パーミッションビットと ACL 項目の比較

最小 ACL (マスク無し) では、グループクラスのパーミッションは所有グループ の ACL 項目に対応します (参照: 図10.1「最小 ACL: パーミッションビットと ACL 項目の比較」) 。 拡張 ACL (マスクあり) では、グループクラスのパーミッションはマスク項目に 対応します (参照: 図10.2「拡張 ACL: パーミッションビットと ACL 項目の比較」) 。

図10.2 拡張 ACL: パーミッションビットと ACL 項目の比較

拡張 ACL: パーミッションビットと ACL 項目の比較

このような対応付けにより、アプリケーション側が ACL に対応しているかどうか に関係なく、円滑な動作を行なうことができるようになっています。つまり、 従来のファイルパーミッションでは大まかな設定を、 ACL では 細かい調整 を行なう形です。また、ファイルパーミッションに 対する変更は ACL 側に自動的に反映されますし、逆も同様です。

10.4.2. ACL の設定されたディレクトリ

getfaclsetfacl のコマンド ラインツールを利用することで、 ACL にアクセスすることができるように なっています。これらのコマンドの使用方法について下記で説明します。

ディレクトリを作成する前に、まずは umask コマンドを 利用して、ファイルなどの要素を作成する際にマスクされるべきファイル パーミッションを設定します。 umask 027 のように実行すると、所有者に対しては既定ですべての 範囲のパーミッション (0) を、所有グループに対しては 書き込みアクセスだけを禁止するパーミッション (2) を、 最後にその他のユーザに対してはすべてのパーミッションを拒否 (7) する意味になります。つまり umask では、マスクして OFF に設定するパーミッションビットを 1 として指定する ことで設定を行ないます。詳しくは umask のマニュアル ページをお読みください。

mkdir mydir を実行すると、 umask で設定した既定のファイルパーミッション設定で mydir ディレクトリを作成します。作成後は、 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 行には 3 種類の ACL 項目が表示され、それぞれ 所有者、所有グループ、その他の項目を表わしています。このように最小 ACL の 場合は、 getfacl で表示できる項目と ls で表示できる項目に差はありません。

追加のユーザ geeko とグループ mascots に対して、読み込みと書き込み、そして実行の権限を設定するよう ACL を修正する には、下記のように実行します:

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

-m オプションは、 setfacl に対して 既存の ACL を修正するように指定するオプションです。続く文字列には修正 対象の ACL 項目 (複数の項目がある場合はカンマで区切ります) が書かれて いて、最後は変更を適用するディレクトリ名を指定しています。上記を実行する と、 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 コマンドでグループクラスとして表示する ことができます。

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

出力の最初の列に + 記号が書かれていますが、これは その項目に 拡張 ACL が存在することを示しています。

ls コマンドの出力によると、マスク項目に書き込みアクセス が含まれていることを示しています。従来はこのような許可ビットが設定されて いた場合、所有グループ (ここでは project3 グループ) は、 mydir ディレクトリへの書き込み権限があることを示す ものでした。しかしながら、ここでは所有グループに対するアクセス許可は、 所有グループに対して設定された ACL の値が有効となります。この例では、 r-x (詳しくは 表10.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 のように実行します。

10.4.3. デフォルト ACL が設定されたディレクトリ

ディレクトリに対してはデフォルト ACL を設定することができます。これは特殊 用途の ACL で、そのディレクトリ内に何らかの要素 (ファイルやサブディレクトリ など) を作成する際、継承されるべきアクセス許可を規定するものです。

10.4.3.1. デフォルト ACL の効果

ディレクトリのデフォルト ACL がファイルやサブディレクトリに渡される 仕組みとしては、下記の 2 つのものがあります:

  • サブディレクトリは、親ディレクトリのデフォルト ACL を、自身のデフォルト ACL と通常の ACL として引き継ぎます。

  • ファイルは、デフォルト ACL を自身の ACL として引き継ぎます。

ファイルシステム内に何らかの要素を作成するすべてのシステムコールでは、 mode というパラメータを使用し、新しく作成するものに 対して設定するアクセス許可を指定します。親ディレクトリにデフォルト ACL が設定されていない場合は、 mode パラメータで渡された アクセス許可から umask の値を差し引いたあと、新しく 作成した要素に設定が行なわれます。親ディレクトリにデフォルト ACL が存在 する場合は、デフォルト ACL に mode パラメータで渡された 設定を被せて設定します。この場合、 umask の設定値は 無視されます。

10.4.3.2. デフォルト ACL の適用例

下記の 3 つの例で、ディレクトリやそのデフォルト ACL に対する主な操作を 説明します:

  1. 既存のディレクトリ mydir に対して、デフォルト ACL を追加するには、下記のように実行します:

    setfacl -d -m group:mascots:r-x mydir

    setfacl-d オプションは、 setfacl に対して 下記の修正 (-m オプション) をデフォルト ACL に 対して適用するよう指定するオプションです。

    下記のコマンド出力をお読みください:

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

    getfacl は通常の ACL とデフォルト ACL の両方を 表示します。デフォルト ACL は default で始まる 行で記されています。単純に setfacl コマンドを デフォルト ACL の mascots グループに対して実行 した場合でも、 setfacl は自動的に通常の ACL 内に 存在する項目をデフォルト ACL としてコピーします。なお、デフォルト ACL はアクセス権に対して即時に効力のあるような仕組みでは無く、 新しくファイルシステムの要素 (ファイルやディレクトリなど) を作成 した際にはじめて効力が現われます。なお新しく作成した要素は、自身が 属する親ディレクトリのデフォルト ACL のみを引き継ぎます。

  2. 次の例では、 mkdir コマンドを利用して mydir 以下にサブディレクトリを作成し、 デフォルト ACL を引き継ぐ仕組みを示しています。

    mkdir mydir/mysubdir
    
    getfacl mydir/mysubdir 
    
    # file: mydir/mysubdir 
    # owner: tux 
    # group: project3 
    user::rwx 
    group::r-x 
    group:mascots:r-x 
    mask::r-x
    other::--- 
    default:user::rwx 
    default:group::r-x
    default:group:mascots:r-x 
    default:mask::r-x 
    default:other::---

    期待の通り、新しく作成されたサブディレクトリ mysubdir には、親ディレクトリのデフォルト ACL がそのまま適用されています。つまり、 mysubdir の ACL は mydir のデフォルト ACL を即時に反映させたものと言えます。このディレクトリの デフォルト ACL は、通常の ACL と同じになっています。

  3. さらに touch コマンドを利用すると、 mydir ディレクトリ内にファイルを作成することが できます。たとえば touch mydir/myfile のように実行すると、 ls -l mydir/myfile は下記のような表示になります:

    -rw-r-----+ ... tux project3 ... mydir/myfile

    また、 getfacl mydir/myfile の出力は 下記のとおりです:

    # file: mydir/myfile 
    # owner: tux 
    # group: project3
    user::rw- 
    group::r-x          # effective:r-- 
    group:mascots:r-x   # effective:r-- 
    mask::r-- 
    other::---

    touch コマンドは、新しくファイルを作成するにあたって mode の設定値を 0666 に設定します。 これは umask やデフォルト ACL で制限を行なわない限り、 すべてのユーザクラスに対して読み書きのアクセスを許可する意味になります (詳しくは 10.4.3.1項 「デフォルト ACL の効果」 を お読みください) 。実際には、 mode の設定値に含まれて いないアクセス許可は関連する ACL 項目から取り除かれます。グループクラス 内の ACL 項目から削除されることはありませんが、その代わりにマスク項目が mode での設定値をマスクするために修正されています。

    このような仕組みにより、 ACL はアプリケーション (たとえばコンパイラ) との 柔軟な対応を実現しています。たとえば制限されたアクセス許可でファイルを 作成して、後からそれらを実行可能なものとしてマークするようなことが できます。つまり mask の仕組みは、正当なユーザと グループが必要に応じて実行できることを保証する仕組みです。

10.4.4. ACL チェックアルゴリズム

チェックアルゴリズムは、 ACL で保護されたファイルシステムの要素に対して、 プロセスやアプリケーションがアクセスしようとしたときに呼び出されます。 基本的なルールとして、 ACL の項目は所有者, 指名ユーザ, 所有グループまたは 指名グループ, その他の順序で解釈されます。また、アクセスはその処理に もっとも当てはまる項目に対して処理されます。なお、アクセス許可が蓄積されて 動作することはありません。

ある特定のプロセスが複数のグループに所属し、それらのグループに該当する ようなアクセス許可があった場合はより複雑な仕組みになります。この場合は 必要なアクセス許可に対して、該当する項目をランダムで抽出します。これは どの項目が最終的に アクセスを許可する のかに関係なく動作 します。同様に必要なアクセス許可を含むグループ項目が存在しない場合は、 ランダムで選択された項目が最終的な アクセス拒否 を発生 させます。

10.5. アプリケーションにおける ACL サポート

ACL は、新しいアプリケーションに対して、とても複雑なアクセス許可シナリオを 実装するために使用するものです。従来のファイルパーミッションの考え方と ACL は、賢い方法で組み合わせることが可能です。基本的なファイルコマンド (cp, mv, ls など) では ACL に対応しているほか、 Samba や Konqueror などでも対応しています。

残念ながら、多くのエディタやファイルマネージャには ACL への対応が用意されて いません。 emacs などでファイルをコピーすると、これらのファイルの ACL は 失われます。エディタなどでファイルを修正する場合は、ファイルの ACL が 保持される場合と保持されない場合がありますが、これはエディタが使用する バックアップ手法によって決まります。エディタが元々のファイルに対して変更 点を書き込む場合は、 ACL は元のまま保持されます。エディタが更新された ファイルを新しいファイルに保存し、あとから古いファイルと新しいファイルとの 間で名前変更を行なうような仕組みの場合は、エディタ側で ACL に対応して いない限り、 ACL の情報は失われます。また star アーカイバを除き、 ACL を保持できるバックアップアプリケーションは現時点では存在していません。

10.6. さらなる情報

ACL についてさらに詳しい情報は、 getfacl(1), acl(5), setfacl(1) の各マニュアル ページをお読みください。


openSUSE セキュリティガイド 13.1