【ITニュース解説】🔐 My DevOps Journey: Part 3 — Linux Users, Groups, Permissions & Package Managers

システムを運用する上で、最も基本的ながら非常に重要な要素の一つに「権限管理」がある。特にLinux環境では、ファイルの操作やソフトウェアのインストールにおいて、しばしば「Permission denied」（権限がありません）というエラーに直面する。このエラーは、単なる入力ミスではなく、Linuxがシステムを安全に保つために設けている重要な仕組みである権限と所有権、そしてシステム全体のソフトウェア管理を担うパッケージマネージャーの理解を深めるきっかけとなるだろう。

まず、Linuxにおけるファイルやディレクトリへのアクセスを制御する基本的な要素として、「ユーザー」「グループ」「パーミッション」がある。 「ユーザー」とは、システムを利用する個人のアカウントを指す。ファイルを作成すると、その作成者がデフォルトでファイルの「所有者」（オーナー）となる。 「グループ」は、複数のユーザーをまとめた集合体で、プロジェクトチームのように、特定のファイルやディレクトリに対して共通の権限を与えたい場合に活用される。 「パーミッション」（権限）とは、ファイルやディレクトリに対して、誰がどのような操作を許可されているかを定義するものである。具体的には「読み込み（r）」「書き込み（w）」「実行（x）」の3種類の権限があり、それぞれがファイルの読み出し、内容の変更、プログラムとしての実行を許可するかどうかを示す。

これらの情報は、ls -lコマンドで確認できる。例えば「-rwxrw-r-- 1 sheersh devops 0 Sep 9 12:00 demo.txt」のような出力があった場合、この文字列は以下のように分解できる。 先頭のハイフンはファイルであることを示し、その後のrwxはファイルの所有者（ここではsheersh）が「読み込み・書き込み・実行」の全ての権限を持つことを意味する。次のrw-は、このファイルが所属するグループ（ここではdevops）のメンバーが「読み込み・書き込み」はできるが「実行」はできないことを示している。最後のr--は、所有者でもグループのメンバーでもない「その他のユーザー」が「読み込み」のみ可能で、「書き込み・実行」はできないことを表す。 これらのパーミッションは、八進数形式で表現することも可能で、例えばrwxrw-r--は764と表せる。ここでrは4、wは2、xは1に対応し、各権限の合計値が数字となる。 ファイルのパーミッションを変更するにはchmodコマンドを使用する。例えば、chmod 764 /home/demo.txtというコマンドは、demo.txtファイルの所有者にrwx、グループにrw-、その他のユーザーにr--の権限を設定する。設定後はls -lで意図した通りになっているか確認することが重要だ。

パーミッションが設定されていても、そのファイルが誰に「所有されているか」（所有権）は非常に重要である。所有権は、誰がそのファイルに対するパーミッションを行使できるかを決定する。たとえファイルに実行権限があっても、誤ったユーザーが所有していると、意図したユーザーが操作できない事態が発生する。 ファイルの所有者やグループを確認するにはls -lコマンドを使用し、これらを変更するにはchown（所有者とグループを変更）やchgrp（グループのみ変更）コマンドを用いる。たとえば、chown newuser:newgroup file.txtはfile.txtの所有者をnewuserに、グループをnewgroupに変更する。 DevOpsの現場では、rootユーザーが作成したファイルやスクリプトを、アプリケーションを実行する特定のユーザーやCI/CDパイプラインが使用する必要がある場合が頻繁に発生する。このような状況で、所有権が正しく設定されていないと、「Permission denied」エラーが発生し、システムが正常に動作しない原因となる。

実際のトラブルシューティングの例として、開発環境では正常に動作したログローテーションスクリプトが、ステージング環境で「bash: ./logrotate.sh: Permission denied」エラーを出して実行できないケースを考える。この場合、まず実行権限の有無を確認するが、もし実行権限があるにもかかわらずエラーが出るのであれば、次に所有権を確認する必要がある。 ls -l logrotate.shで確認した結果、スクリプトがroot:rootに所有されていることが判明したとしよう。開発者はdevグループに属しているが、ファイルがroot:rootに所有されているため、たとえファイルにrwxrwxr--というパーミッション（グループには読み書き実行権限があるように見える）が付与されていても、開発者が所属するdevグループはrootグループとは異なるため、このrwx権限は適用されず、結果として実行できない状態となる。 この問題を解決するには、sudo chown dev:dev logrotate.shのように、スクリプトの所有者をdevユーザーに、グループをdevグループに変更する。これにより、devユーザーとしてログインした開発者は、スクリプトを実行できるようになる。この事例から、「パーミッションが許可されるアクションを制御し、所有権が誰がそのパーミッションを行使できるかを制御する」という重要な教訓が得られる。

ファイルやディレクトリの権限管理が理解できると、次に「パッケージマネージャー」という概念に進む。パッケージマネージャーは、Linuxシステム上でソフトウェアのインストール、アップデート、削除、および依存関係の管理を行うためのツールである。パーミッションが個々のファイルへのアクセスを制御するのに対し、パッケージマネージャーはシステム全体のソフトウェアのライフサイクルを管理する。 Linuxディストリビューションによって使用されるパッケージマネージャーは異なり、例えばUbuntuやDebianでは「APT（Advanced Package Tool）」、CentOSやFedora、RHELでは「YUM/DNF」、openSUSEでは「Zypper」、Arch Linuxでは「Pacman」などが一般的だ。これらのツールは、sudo apt install nginxやsudo dnf install nginxのように、簡単なコマンドで必要なソフトウェアとその依存関係をまとめてインストールできる。

パッケージマネージャーの操作も、パーミッションの概念と密接に関わっている。システム全体にソフトウェアをインストールしたりアップデートしたりする操作は、システムの重要なディレクトリ（/usr/binや/etcなど）を変更するため、特別な権限が必要となる。そのため、パッケージマネージャーのコマンドを実行する際には、多くの場合sudo（スーパーユーザー権限でコマンドを実行）を使用するか、rootユーザーとして実行する必要がある。 もし一般ユーザーがapt install nginxのようなコマンドをsudoなしで実行しようとすると、「E: Could not open lock file /var/lib/dpkg/lock-frontend - Permission denied」のようなエラーに直面する。これは、パッケージマネージャーがシステムファイルを変更するために必要なロックファイルへの書き込み権限がないためである。解決策は、sudo apt install nginxのようにsudoを付けてコマンドを再実行することだ。このことから、パッケージマネージャーとパーミッションは、個別のファイルを保護するだけでなく、オペレーティングシステム全体を保護するための強力なメカニズムであることがわかる。

これらの学びを通じて、Linuxにおけるファイルやソフトウェアの操作で発生する「Permission denied」エラーの背後には、ユーザー、グループ、パーミッション、所有権、そしてパッケージマネージャーという複合的なセキュリティと管理の仕組みが存在することが理解できる。システムエンジニアを目指す上で、これらの基本的な概念を深く理解し、トラブルシューティングに応用できる能力は非常に重要である。