【ITニュース解説】Stop Using chmod 777 for One Extra User: Practical POSIX ACLs on Linux

システムエンジニアを目指す初心者がLinuxのファイル権限を扱う際、特定のユーザーに一時的にアクセスを許可したい場面は多くあるだろう。そのような状況で、手軽な解決策として chmod 777 というコマンドを使いたくなるかもしれない。しかし、このコマンドはすべてのユーザーにファイルやディレクトリへのあらゆるアクセス権を与えてしまい、セキュリティ上の大きな問題を引き起こす。社内の機密情報や重要なシステムファイルが、意図せず全世界に公開されてしまう危険があるため、安易な chmod 777 の使用は絶対に避けるべきだ。

次に考えられる方法として、アクセスを許可したいユーザーを、そのファイルやディレクトリを所有するグループに追加することが挙げられる。この方法は chmod 777 よりは安全だが、いくつかの副作用があることを理解しておく必要がある。ユーザーをグループに追加すると、そのユーザーはそのグループが所有するすべてのファイルやディレクトリに対して同じアクセス権を持つことになる。つまり、特定のディレクトリだけにアクセスを許可したつもりが、意図せず他の多くの場所にもアクセスできる状態になってしまう可能性があるのだ。また、グループメンバーシップの変更は、ユーザーが現在ログインしているセッションにはすぐに反映されないことがあり、変更を適用するためには再ログインが必要になる場合もある。

このような、特定のオブジェクト（ファイルやディレクトリ）に対して、特定のユーザーやグループにだけ、所有者やグループを変更したり全員に公開したりすることなく、細かくアクセス権を設定したいという場合に役立つのが「POSIX ACLs (Access Control Lists)」という仕組みである。ACLsはLinuxの多くの主要なファイルシステム（ext4、XFS、Btrfsなど）で標準的にサポートされており、古くから存在する機能だ。ACLsは、従来の「所有者」「所有グループ」「その他のユーザー」という3つの権限の枠組みに、さらに柔軟なアクセス制御の仕組みを追加するもので、既存の権限モデルを置き換えるのではなく、拡張する形で機能する。

ACLsは「アクセスACL」と「デフォルトACL」の二種類に分けられる。アクセスACLはそのファイルやディレクトリ自体へのアクセスを制御するもので、一方デフォルトACLはディレクトリにのみ設定でき、そのディレクトリ内に新しく作成されるファイルやディレクトリがどのようなACLを継承するかを定義する役割を持つ。アクセスACLは必ず「user::（所有者）」、「group::（所有グループ）」、「other::（その他のユーザー）」という3つの基本エントリを含む。これに加えて、「user:名前:」や「group:名前:」といった特定ユーザーや特定グループのためのエントリを自由に追加できる。

ACLを扱う上で特に理解しておくべき重要な概念が「マスク (mask::)」である。名前付きユーザーやグループのエントリを追加すると、自動的にこのマスクエントリが作成される。マスクは、「user:名前:」や「group:名前:」、そして「group::（所有グループ）」によって付与されるアクセス権の「天井」として機能する。つまり、マスクが許可しない権限は、たとえ個別のエントリで許可されていても実際には付与されないのだ。ただし、所有者（user::）とその他のユーザー（other::）にはマスクは適用されない。このマスクの振る舞いが、ACL設定で最も混乱しやすい点の一つである。

従来の ls -l コマンドでファイルの詳細を表示すると、グループ権限の欄に「rwx」のような表示が見られる。しかし、ACLが設定されている場合、このグループ権権限の表示は、実際の所有グループの権限ではなく、ACLのマスクエントリの権限を示していることが多い。このため、ls -l の表示だけを信用すると、実際の権限と異なる解釈をしてしまう可能性がある。ACLが設定されているかどうかは、ls -l の出力末尾に「+」が表示されることで判断できるが、真のACLの状態を確認するためには getfacl コマンドを使用する必要がある。

ACLを設定するには setfacl コマンドを、確認するには getfacl コマンドを使用する。例えば、sudo setfacl -m u:deploy:rwX /srv/app/uploads と実行すると、deploy というユーザーに /srv/app/uploads ディレクトリへの読み取り、書き込み、実行（ディレクトリの場合は踏み込み）権限を付与できる。ここで使われている大文字の X は、対象がディレクトリの場合にのみ実行権限を、それ以外の場合には読み書き権限のみを付与するという便利な機能だ。このコマンドを実行すると、自動的に mask:: エントリが生成され、getfacl で確認できるようになる。

しかし、ACLを設定した後でも、chmod コマンドの誤った使用によって、設定したACLが意図せず無効になってしまうという落とし穴がある。chmod 700 /srv/app/uploads のように実行すると、所有者にはフルアクセスを、グループとその他のユーザーには一切アクセス権を与えないという指示になる。ここで注意すべきは、ACLが存在する場合、chmod コマンドのグループ権限ビットはACLのマスクエントリに対応しているという点だ。したがって、chmod 700 を実行すると、グループ権限を「なし」に設定するのと同時に、ACLのマスクも「なし」に設定されてしまう。マスクが「なし」になると、名前付きユーザーのエントリで付与された権限もすべて無効になってしまうため、deploy ユーザーはアクセスできなくなる。これはバグではなく、chmod がモードビットを通じてマスクを直接変更するという仕様に基づいている。このような問題を避けるためには、setfacl で権限を付与する際にマスクも -m u:deploy:rwX,m::rwx のように明示的に指定するか、chmod を実行した後に必ず getfacl でACLの状態を再確認する習慣をつけることが重要だ。

デフォルトACLは、共有ディレクトリなどで新しく作成されるファイルやディレクトリに特定の権限を自動的に継承させたい場合に非常に有用だ。sudo setfacl -d -m u::rwx,g::r-x,m::r-x,o::---,u:deploy:r-x /srv/app/uploads のように -d オプションを付けて設定すると、そのディレクトリ内で作成される新しいオブジェクトが、指定されたACLを継承するようになる。デフォルトACLが設定されている場合、ファイルの作成時に適用される umask とは異なり、作成モードとデフォルトACLが最終的な権限を決定するため、共有ツリーでのアクセス管理が容易になる反面、セキュリティレビュー時には注意が必要となる。ただし、デフォルトACLは既存のファイルには影響しないため、既存のファイルにも適用したい場合は setfacl -R コマンドと find コマンドを組み合わせて再帰的に適用する必要がある。

ACLを削除する際には、setfacl -x で特定のエントリを削除したり、setfacl -b で拡張アクセスエントリをすべて削除したり、setfacl -k でデフォルトACLのみを削除したりできる。しかし、-R オプションを付けて再帰的に削除する際は、誤って他のチームが設定したACLまで削除してしまわないよう、getfacl -R -s コマンドを使って、実際に拡張ACLが設定されているファイルやディレクトリを事前に確認することが賢明である。

ACLはファイルのinodeの拡張属性として保存されるため、ファイルのバックアップ、コピー、移動を行う際には注意が必要だ。getfacl -R -p /srv/app > /root/srv-app.acl のようにバックアップし、setfacl --restore=/root/srv-app.acl で復元できる。tar --acls や rsync -aAX、cp -p といったコマンドはACLを保持するが、単なる cp コマンドではACLが失われる可能性がある。同じファイルシステム内での mv コマンドはACLを保持する。重要なことは、ACLを保存できない状況では、ツールが警告を発したり失敗したりするようになっているため、スクリプトでこれらの操作を行う際は終了ステータスを必ず確認することだ。

ACLの変更には、ファイルの所有者であるか、CAP_FOWNER 権限を持つ必要がある。通常のLinuxシステムでは、これは root ユーザーかファイルの所有者を意味するため、特定のディレクトリツリーのACL管理を誰かに委譲することは、特権的な操作を委譲することになる点を理解しておくべきだ。

最後に、ACLを設定した後は、設定内容を getfacl で確認するだけでなく、実際にアクセスを必要とするユーザーになりすまして、期待通りにアクセスできるかをテストすることが非常に重要だ。例えば、sudo -u deploy test -w /srv/app/uploads && echo "write: ok" のように test コマンドを使えば、deploy ユーザーとして書き込みが可能かを確認できる。また、getfacl -t -R /srv/app コマンドを使うと、マスクによって無効になっている権限が分かりやすく大文字で表示されるため、問題の早期発見に役立つだろう。

chmod 777 のような広範な権限付与は、単一ユーザーの環境では問題にならないかもしれないが、複数のユーザーやサービスが動作するシステムではセキュリティリスクの温床となる。ACLは、特定のユーザーやサービスアカウントにだけ必要な最小限の権限を付与し、かつその設定が監査可能であるため、セキュアなシステム運用において非常に有効な手段だ。基本的には、最も厳密な権限モードを設定し、その上でACLを使って例外的なアクセス権を最小限に付与し、マスクも明示的に設定し、最後に実際にターゲットユーザーとして検証するという流れが推奨される。この実践によって、将来的なセキュリティインシデントのリスクを低減し、より堅牢なシステムを構築できるようになるだろう。