Linuxのユーザー権限とパーミッションの基礎知識

Linuxのユーザー権限とパーミッションは、システムセキュリティの根幹を成す重要な仕組みです。この記事では、基本的な概念から実務での注意点まで、現場で死なないための知識を体系的に解説していきます。

初学者の方も、中堅手前の方も、ぜひこの機会に理解を深めてください。

Linuxにおけるユーザーとグループの基本

Linuxはマルチユーザーシステムです。複数のユーザーが同じシステムを共有しながら、お互いのファイルやプロセスを保護する仕組みが必要です。そのために「ユーザー」と「グループ」という概念が存在します。

ユーザーの種類

Linuxには大きく分けて3種類のユーザーが存在します。

1. rootユーザー（スーパーユーザー）

システム全体に対する完全な権限を持つ特別なユーザーです。UID（User ID）は常に0です。

$ id root
uid=0(root) gid=0(root) groups=0(root)

rootユーザーは何でもできる反面、誤操作によるシステム破壊のリスクも最大です。そのため、実務では日常的にrootでログインすることは避け、必要なときだけsudoコマンドで権限を昇格させるのが鉄則です。

2. システムユーザー

Apacheやnginx、MySQLなどのサービスを実行するために作られる特殊なユーザーです。通常、UIDは1～999の範囲で作成されます。

$ grep nginx /etc/passwd
nginx:x:998:996:Nginx web server:/var/lib/nginx:/sbin/nologin

システムユーザーの多くは/sbin/nologinがシェルに設定されており、対話的なログインができないようになっています。これはセキュリティ対策の一環です。

3. 一般ユーザー

実際に人間が使用するアカウントです。UIDは通常1000以降で作成されます。

$ id iwata
uid=1000(iwata) gid=1000(iwata) groups=1000(iwata),27(sudo)

グループとは

グループは複数のユーザーをまとめて管理するための仕組みです。これにより、特定のファイルやディレクトリへのアクセス権を、個別のユーザーではなくグループ単位で設定できます。

たとえば、開発チームのメンバー全員をdevelopersというグループに所属させれば、プロジェクトディレクトリへのアクセス権限を一括で管理できます。

$ groups iwata
iwata : iwata sudo developers

この出力は、ユーザーiwataがiwata（プライマリグループ）、sudo、developersの3つのグループに所属していることを示しています。

ユーザー情報の確認方法

現在ログインしているユーザーの情報を確認するにはidコマンドを使います。

$ id
uid=1000(iwata) gid=1000(iwata) groups=1000(iwata),27(sudo),1001(developers)

このコマンドは、UID、GID（Group ID）、所属グループの一覧を表示します。トラブルシューティング時に「今自分がどのユーザーで、どのグループに所属しているか」を確認するのは基本中の基本です。

パーミッション（アクセス権限）の仕組み

Linuxでは、すべてのファイルとディレクトリにパーミッション（アクセス権限）が設定されています。これにより、「誰が」「何を」できるかが厳密に制御されます。

パーミッションの3つの対象

パーミッションは以下の3つの対象に対して設定されます。

1. 所有者（Owner）: ファイルを作成したユーザー
2. グループ（Group）: ファイルに設定されたグループ
3. その他（Others）: 上記以外のすべてのユーザー

パーミッションの3つの種類

各対象に対して、以下の3つの権限を設定できます。

パーミッションの表示方法

ls -lコマンドでファイルの詳細情報を表示すると、パーミッションが確認できます。

$ ls -l /etc/passwd
-rw-r--r-- 1 root root 2341 Jan 20 10:15 /etc/passwd

この出力を詳しく見ていきましょう。

-rw-r--r--

この10文字の意味は以下の通りです。

ファイルタイプの種類

1文字目のファイルタイプには以下のような種類があります。

実務で最もよく見るのは-（ファイル）、d（ディレクトリ）、l（シンボリックリンク）の3つです。

パーミッションの数値表記

パーミッションは数値でも表現できます。これを8進数表記と呼びます。

これらを足し合わせることで、パーミッションを3桁の数字で表現します。

たとえば、rw-r--r--は644、rwxr-xr-xは755となります。今は無理かもしれないですが、この3桁の数字を見て一瞬でパーミッションが分かれば、中級者と言えるでしょう。

パーミッションの変更方法

パーミッションを変更するにはchmod（change mode）コマンドを使います。

数値指定による変更

最もシンプルで確実な方法です。

$ chmod 644 file.txt

これにより、file.txtのパーミッションがrw-r--r--（所有者は読み書き可、グループとその他は読み取りのみ）に設定されます。

よく使うパーミッション設定

実務でよく使うパーミッション設定をまとめます。

記号指定による変更

既存のパーミッションに対して、部分的に権限を追加・削除する場合は記号指定が便利です。

$ chmod u+x script.sh

これは「所有者（u）に実行権限（x）を追加（+）する」という意味です。

記号の意味

記号指定の例

$ chmod g+w file.txt

グループに書き込み権限を追加します。

$ chmod o-r file.txt

その他のユーザーから読み取り権限を削除します。

$ chmod a+x script.sh

すべてのユーザーに実行権限を追加します。

$ chmod u=rw,g=r,o= file.txt

所有者には読み書き、グループには読み取りのみ、その他には何も許可しません。

ディレクトリに対する再帰的な変更

ディレクトリとその中身すべてのパーミッションを一括で変更するには、-Rオプションを使います。

$ chmod -R 755 /var/www/html

ただし、ディレクトリとファイルで適切なパーミッションは異なるため、再帰的な変更には注意が必要です。この点は後述の「実務の落とし穴」で詳しく解説します。

所有者とグループの変更方法

ファイルやディレクトリの所有者とグループを変更するには、chown（change owner）とchgrp（change group）コマンドを使います。

所有者の変更

$ sudo chown iwata file.txt

file.txtの所有者をiwataに変更します。

所有者とグループの同時変更

$ sudo chown iwata:developers file.txt

所有者をiwata、グループをdevelopersに変更します。

グループのみの変更

$ sudo chgrp developers file.txt

グループのみをdevelopersに変更します。

再帰的な変更

$ sudo chown -R iwata:developers /home/iwata/project

ディレクトリとその中身すべての所有者とグループを変更します。

特殊なパーミッション

通常のパーミッション（rwx）以外に、Linuxには3つの特殊なパーミッションがあります。実務では必須の知識です。

SUID（Set User ID）

ファイル実行時に、所有者の権限で実行されるという特殊な権限です。数値では4000、記号ではsで表されます。

$ ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root 68208 Jan 15 10:23 /usr/bin/passwd

所有者の実行権限部分がsになっています。これがSUIDです。

passwdコマンドは、一般ユーザーが自分のパスワードを変更するために使いますが、実際には/etc/shadowというroot権限でしか書き込めないファイルを編集する必要があります。SUIDが設定されているため、一般ユーザーが実行してもroot権限で動作し、パスワード変更が可能になります。

SUIDの設定方法

$ sudo chmod u+s file

または

$ sudo chmod 4755 file

現場での注意点

SUIDは強力すぎるため、安易に設定してはいけません。悪意のあるユーザーが、SUID付きの実行ファイルを悪用すると、root権限を奪取される可能性があります。本番環境では、SUID付きファイルを定期的に監査することが推奨されます。

$ find / -perm -4000 -type f 2>/dev/null

このコマンドで、システム内のすべてのSUID付きファイルを検索できます。

SGID（Set Group ID）

ファイルに対するSGID

ファイル実行時に、グループの権限で実行されるという権限です。数値では2000、記号ではsで表されます。

ディレクトリに対するSGID

ディレクトリにSGIDを設定すると、そのディレクトリ内で作成されたファイルは、親ディレクトリのグループを自動的に継承します。

$ mkdir /shared
$ sudo chgrp developers /shared
$ sudo chmod 2775 /shared

$ ls -ld /shared
drwxrwsr-x 2 root developers 4096 Jan 31 10:00 /shared

グループの実行権限部分がsになっています。

この設定により、/sharedディレクトリ内で誰がファイルを作成しても、自動的にdevelopersグループに所属します。共有ディレクトリを運用する際の定番設定です。

スティッキービット（Sticky Bit）

ディレクトリ内のファイルを削除できるのは、所有者とroot のみという制限をかける権限です。数値では1000、記号ではtで表されます。

$ ls -ld /tmp
drwxrwxrwt 12 root root 4096 Jan 31 10:00 /tmp

その他の実行権限部分がtになっています。

/tmpは誰でも書き込み可能ですが、スティッキービットが設定されているため、自分が作成したファイルは自分しか削除できません。これにより、他人のファイルを勝手に削除される危険を防いでいます。

スティッキービットの設定方法

$ sudo chmod +t /shared

または

$ sudo chmod 1777 /shared

umask – デフォルトパーミッションの制御

ファイルやディレクトリを新規作成したとき、どのようなパーミッションが設定されるかを制御するのがumaskです。

umaskの仕組み

umaskは「マスク値」として機能します。新規ファイルやディレクトリのパーミッションは、基本値からumask値を引いた値になります。

• ファイルの基本値: 666（rw-rw-rw-）
• ディレクトリの基本値: 777（rwxrwxrwx）

たとえば、umaskが022の場合：

• ファイル: 666 - 022 = 644（rw-r--r--）
• ディレクトリ: 777 - 022 = 755（rwxr-xr-x）

現在のumask値の確認

$ umask
0022

4桁表示されますが、最初の0は特殊パーミッションを表すため、通常は3桁の022として扱います。

umaskの設定

$ umask 027

これにより、以降作成するファイルとディレクトリのデフォルトパーミッションが変更されます。

実際に確認してみましょう。

$ touch test_file
$ mkdir test_dir
$ ls -ld test_file test_dir
-rw-r----- 1 iwata iwata 0 Jan 31 10:30 test_file
drwxr-x--- 2 iwata iwata 4096 Jan 31 10:30 test_dir

umask 027の場合、ファイルは640、ディレクトリは750になります。

umaskの恒久的な設定

シェルを起動するたびにumaskを設定するのは面倒です。恒久的に設定するには、~/.bashrcや/etc/profileに記述します。

$ echo "umask 027" >> ~/.bashrc
$ source ~/.bashrc

実務の落とし穴

ここからは、実務でよく遭遇するパーミッション関連のトラブルと、その対処法を紹介します。

1. 安易に777や666を設定してしまう

最も危険なミスの一つです。「とりあえず動けばいい」と考えて、以下のようなコマンドを実行してしまうケースがあります。

$ chmod 777 /var/www/html -R

これは絶対にやってはいけません。すべてのユーザーが書き込み・実行可能になるため、マルウェアの侵入や改ざんのリスクが飛躍的に高まります。

正しい対処法

問題の本質を理解し、必要最小限の権限を付与します。たとえば、Webサーバーが読み取れればいいのであれば：

$ sudo chown -R www-data:www-data /var/www/html
$ sudo chmod -R 755 /var/www/html

ファイルには644、ディレクトリには755を設定するのが基本です。

2. ディレクトリとファイルで適切なパーミッションが異なることを理解していない

chmod -R 644のように、ディレクトリに再帰的に644を設定してしまうと、ディレクトリに実行権限がなくなり、cdでディレクトリに入れなくなります。

$ chmod -R 644 /var/www/html
$ cd /var/www/html
bash: cd: /var/www/html: Permission denied

正しい対処法

findコマンドを使って、ディレクトリとファイルを分けて処理します。

$ find /var/www/html -type d -exec chmod 755 {} \;
$ find /var/www/html -type f -exec chmod 644 {} \;

1行目でディレクトリに755を、2行目でファイルに644を設定します。

3. 秘密鍵や機密ファイルのパーミッションが緩い

SSH秘密鍵（~/.ssh/id_rsaなど）のパーミッションが緩いと、SSHが接続を拒否します。

$ chmod 644 ~/.ssh/id_rsa
$ ssh user@server
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/iwata/.ssh/id_rsa' are too open.

正しい対処法

秘密鍵は必ず600（所有者のみ読み書き可能）に設定します。

$ chmod 600 ~/.ssh/id_rsa
$ chmod 700 ~/.ssh

同様に、/etc/shadowや設定ファイル内のパスワードなど、機密性の高いファイルは適切に保護する必要があります。

4. rootで作業してしまい、所有者がrootになる

開発用ディレクトリで作業する際、誤ってsudoを使ってファイルを作成してしまうと、所有者がrootになります。

$ sudo touch /home/iwata/project/file.txt
$ ls -l /home/iwata/project/file.txt
-rw-r--r-- 1 root root 0 Jan 31 10:45 /home/iwata/project/file.txt

この状態では、一般ユーザーiwataがこのファイルを編集できません（グループとその他には書き込み権限がないため）。

正しい対処法

不要なsudoは使わないこと。もし誤って作成してしまった場合は、所有者を変更します。

$ sudo chown iwata:iwata/home/iwata/project/file.txt

5. 実行権限の付け忘れ

スクリプトファイルを作成したのに、実行権限がなくて実行できないケースです。

$ cat > script.sh << 'EOF'
#!/bin/bash
echo "Hello, World!"
EOF

$ ./script.sh
bash: ./script.sh: Permission denied

正しい対処法

実行権限を付与します。

$ chmod +x script.sh
$ ./script.sh
Hello, World!

シバン（#!/bin/bash）を書いているのに実行権限がないと、スクリプトとして認識されません。

6. SGIDを理解せず共有ディレクトリを運用する

複数人で共有するディレクトリを作成したものの、SGIDを設定していないため、各ユーザーが作成したファイルのグループがバラバラになってしまうケースです。

$ mkdir /shared
$ chmod 775 /shared
$ chgrp developers /shared

この状態で、異なるユーザーがファイルを作成すると：

# ユーザーiwataがファイル作成
$ touch /shared/iwata_file.txt
$ ls -l /shared/iwata_file.txt
-rw-r--r-- 1 iwata iwata 0 Jan 31 11:00 /shared/iwata_file.txt

グループがiwata（プライマリグループ）になってしまい、developersグループのメンバーが書き込めません。

正しい対処法

SGIDを設定します。

$ chmod 2775 /shared

これで、作成されるファイルは自動的にdevelopersグループに所属し、グループメンバー全員が書き込めるようになります。

7. パーミッション変更したのに反映されない（NFS環境）

NFS（Network File System）でマウントされたディレクトリでは、クライアント側でパーミッションを変更しても、サーバー側のUID/GIDとの対応が取れていないと正しく機能しません。

正しい対処法

NFS環境では、クライアントとサーバーでUID/GIDを統一するか、IDマッピング機能を使用します。これは少々高度な内容なので、NFS環境でパーミッション問題に遭遇したら、まずUID/GIDの対応を確認してください。

まとめ

この記事では、Linuxのユーザー権限とパーミッションについて、基礎から実務レベルまで解説しました。重要なポイントを以下にまとめます。

覚えておくべき基本知識

• Linuxはマルチユーザーシステムで、ユーザーとグループでアクセス制御を行う
• パーミッションは所有者、グループ、その他の3つの対象に対して設定される
• 権限は読み取り（r）、書き込み（w）、**実行（x）**の3種類
• パーミッションは記号表記（rwx）と数値表記（755など）の両方で表現できる

よく使うコマンド

• chmod: パーミッションの変更
• chown: 所有者とグループの変更
• chgrp: グループの変更
• umask: デフォルトパーミッションの制御

実務で重要な設定値

絶対に避けるべきこと

• 777や666を安易に設定しない – セキュリティリスクが極めて高い
• root権限での不要な作業をしない – 所有者がrootになってしまう
• 秘密鍵のパーミッションを緩くしない – 600必須
• ディレクトリとファイルを区別せず一括変更しない – findで分けて処理

特殊なパーミッション

• SUID（4000）: 実行時に所有者の権限で動作
• SGID（2000）: ディレクトリ内で作成されたファイルがグループを継承
• スティッキービット（1000）: ファイル削除を所有者のみに制限

パーミッションの理解は、Linuxを安全に運用するための基礎中の基礎です。この記事で解説した内容を実際に手を動かして試し、体に染み込ませてください。

実務では、「動けばいい」ではなく「安全に動く」ことが求められます。適切なパーミッション設定を心がけ、セキュアなシステム運用を実現していきましょう。

WRITTEN BY

いわた

外資系IT企業勤務のインフラエンジニア。「できれば働きたくない人。」を目指し、実務を効率化する技術を備忘録としてまとめています。