第2章 2-6 / ユーザーと権限 ― yumiを迎える

権限総合演習

このページで叩くコマンドと到達点

前提:2-5が完了し、グループdevteamが存在・yumiが所属済み。ubuntuユーザーのホームディレクトリ(~)にいる状態から始めます。第2章の締めくくりとして、これまで学んだsudo・su -・chmod・chown・chgrpを総動員し、ubuntuとyumiが一緒に使える共有ディレクトリ/home/sharedを作ります。書き込みが成功する体験と、権限を変えたことでわざと失敗する体験の両方を経て、最後は演習で使ったディレクトリをきれいに片付けます。

SET 1 ― 共有ディレクトリを作る

ubuntu@lightsail: ~
  1. $pwd
  2. /home/ubuntu
  3. $ls /home
  4. $sudo mkdir /home/shared
  5. $ls -ld /home/shared
  6. drwxr-xr-x 2 root root 4096 Jul 3 10:00 /home/shared
  7. $sudo chown ubuntu:devteam /home/shared
  8. $ls -ld /home/shared
  9. drwxr-xr-x 2 ubuntu devteam 4096 Jul 3 10:00 /home/shared
  10. $chmod 770 /home/shared
  11. $ls -ld /home/shared
  12. drwxrwx--- 2 ubuntu devteam 4096 Jul 3 10:00 /home/shared
  13. $groups
  14. $getent group devteam
解説 ― SET 1 で何をしたか

1行目のpwdで現在地を確認したうえで、2行目のls /homeで、今はubuntuとyumiという2つのホームディレクトリしか存在しないことを確認しておきます。3行目のsudo mkdir /home/sharedで、共有場所となる新しいディレクトリを/home直下に作ります。/homeは本来root(またはそれに準じる権限)しか直接書き込めない場所なので、ディレクトリ作成にsudoが必要です。4行目で確認すると、出力例のように所有者・グループともrootという、作成直後のまだ「誰の物でもない」状態になっています。

5行目のsudo chown ubuntu:devteam /home/sharedで、2-5で学んだ書き方を使い、所有者をubuntu、所有グループをdevteamに一度に設定します。rootが所有する領域を書き換える操作なのでsudoが必要です。6行目で確認すると、出力例のとおり持ち主が変わっています。ここで「所有グループをdevteamにした」ことが重要です。これで「devteamグループに所属する全員」がこのディレクトリのグループとしての権限の対象になります。

7行目のchmod 770※1 /home/sharedは2-4で学んだ数字指定です。7(所有者=rwx)・7(グループ=rwx)・0(その他=なし)という組み合わせで、「所有者ubuntuと、devteamグループのメンバーだけが読み書き実行でき、それ以外は一切アクセスできない」という設定になります。すでに所有者(root)によって作成済みのディレクトリなので、この行にはsudoが付いていません。今の所有者であるubuntu自身が、自分の持ち物に対してchmodする分にはsudoは不要です。8行目で確認すると、出力例drwxrwx---のとおり、その他の権限が完全に閉じています。

9行目のgroupsで、自分(ubuntu)がdevteamグループに所属していないことを確認しておきます。ubuntuはこのディレクトリの所有者としてアクセスできますが、devteamのグループメンバーとしてではありません。最後の10行目のgetent group devteamで、2-5で追加したyumiがまだ唯一のメンバーであることも確認しておきます。この違いを意識しながら次のSETに進みます。

POINT

770という数字は、2-4のまとめ表にあった755や644と並ぶ実務の定番です。「身内(所有者+グループ)だけに全権を与え、外部を完全に締め出す」共有フォルダの典型的な設定として覚えておくと便利です。

ゆみちゃん
ゆみ

ubuntuさんとあたしだけが入れる部屋ができたんだね、なんか嬉しいな! chownで持ち主を決めて、chmod 770で「身内だけOK、部外者はお断り」にする流れ、2-4と2-5でバラバラに練習した技がここでつながる感じがして気持ちいいよ。この後実際にあたしが書き込めるか、確かめてみようね!

SET 2 ― yumiとして書き込みに成功する

ubuntu@lightsail: ~
  1. $whoami
  2. ubuntu
  3. $su - yumi
  4. Password: (yumiのパスワードを入力)
yumi@lightsail: ~
  1. $whoami
  2. $groups
  3. yumi devteam
  4. $cd /home/shared
  5. $touch yumi-report.txt
  6. $echo 'yumiから報告です' > yumi-report.txt
  7. $cat yumi-report.txt
  8. $ls -l
  9. -rw-rw-r-- 1 yumi devteam 10 Jul 3 10:05 yumi-report.txt
  10. $exit
解説 ― SET 2 で何をしたか

1行目のwhoamiで改めて今ubuntuであることを確認したうえで、2行目のsu - yumi(2-3で学んだ完全なユーザー切り替え)でyumiとしてログインします。3行目のwhoamiで無事yumiに切り替わったことを確認し、4行目のgroupsを確認すると、出力例のとおりyumi devteamとなっています。2-5でSET 2の直後に注意したとおり、usermod -aGによるグループ追加は新しくログインし直すことで反映されるタイミング※4があるため、ここで初めてyumiのセッションにもdevteam所属が有効になります。

5行目のcd /home/sharedで共有ディレクトリに移動します。SET 1で設定した770のグループ権限(rwx)のおかげで、devteamのメンバーであるyumiはこのディレクトリに入ることができます。6〜7行目でtouchとechoを使い、実際にファイルを作成・書き込みし、8行目のcatで書き込んだ内容を確認します。9行目のls -lで確認すると、出力例のとおり所有者yumi・グループdevteamのファイルが問題なく作成できています。ここでsudoは一切使っていません。root権限を借りなくても、正しくグループ設定されたディレクトリでは一般ユーザー同士がファイルを共有できる、というのがこのセットの到達点です。

10行目のexitでyumiのセッションを終え、ubuntuユーザーに戻ります。

POINT

「sudoを使わずに複数人でファイルを共有できる」のが、グループとパーミッションを正しく設計する最大のメリットです。管理者権限をむやみに配らなくても、devteamのようなグループ単位で協業できる仕組みこそが、実際のチーム開発の現場でも使われている考え方です。

SET 3 ― 権限を絞って失敗を体験し、片付ける

ubuntu@lightsail: ~
  1. $ls /home/shared
  2. $chmod 700 /home/shared
  3. $ls -ld /home/shared
  4. drwx------ 2 ubuntu devteam 4096 Jul 3 10:05 /home/shared
  5. $su - yumi
yumi@lightsail: ~
  1. $cd /home/shared
  2. bash: cd: /home/shared: Permission denied
  3. $cat /home/shared/yumi-report.txt
  4. cat: /home/shared/yumi-report.txt: Permission denied
  5. $exit
ubuntu@lightsail: ~
  1. $whoami
  2. ubuntu
  3. $sudo rm -r /home/shared
  4. $ls /home
解説 ― SET 3 で何をしたか

1行目のls /home/sharedで、SET 2でyumiが作ったyumi-report.txtが所有者ubuntuの権限でも問題なく見えることを確認しておきます。2行目のchmod 700 /home/sharedで、あえて権限を絞り込みます。700※2は「所有者(ubuntu)のみ全権、グループも含めて他は一切不可」という設定です。3行目で確認すると、出力例drwx------のとおり、SET 1で与えていたグループのrwxが消えています。

4行目で再びyumiに切り替え、5行目でcd /home/sharedを試すと、今度は出力例のようにPermission denied※5で拒否されます。SET 2では同じdevteamグループの一員として難なく入れたのに、所有者がchmodでグループ権限を外した瞬間、devteamのメンバーであるyumiも締め出されてしまいました。6行目のように、ディレクトリに入れないだけでなく、中のファイルを直接指定して読もうとしても同様に拒否されます。これは2-3・2-4で学んだ内容の総まとめです。ファイルへのアクセスは「誰であるか」だけでなく「今その瞬間にどんな権限が設定されているか」で決まる、ということをこの失敗体験で確認してください。7行目のexitでyumiのセッションを終えます。

8行目のwhoamiでubuntuに戻ったことを確認し、9行目、sudo rm -r /home/sharedを実行します。この講座では章の終わりに演習用の共有物を片付けるという約束になっているため、/home/sharedディレクトリを中身ごと削除します。rm -r※3(1-3で学んだ再帰的削除)は/home直下という他人の目にも触れる場所を操作するためsudoが必要です。この講座でrm -rを使うときは必ず対象のパスを指差し確認する癖をつけてください。/home/sharedのように明確な練習用ディレクトリだけを対象にし、間違っても/homeだけを消してしまわないよう、コマンドの綴りは慎重に確認しましょう。最後の10行目のls /homeで、sharedディレクトリがきれいに消え、ubuntuとyumiだけの状態に戻ったことを確認し、このページと第2章を締めくくります(すでに~にいるため、あらためてcd ~を打つ必要はありません)。

ゆみちゃん
ゆみ

さっきまで入れてた部屋に急に入れなくなって、正直めちゃくちゃびっくりしたよ! でもこれ、実際の仕事でもよくある話みたいで、「あれ、昨日まで開けたファイルが急に開けない」ってなったら、大体は誰かが権限を変えたのが原因なんだって。焦らずls -ldで今の権限を確認する、が合言葉だね。2章、本当にお疲れさま! 次は3章でテキストの読み書きに挑戦だよ!

POINT

第2章はここで完結です。サーバー上には練習用ユーザーyumiとグループdevteam(yumiが所属)が残り、演習で使った/home/sharedは片付けました。~/practiceディレクトリとその中身は引き続き残っているので、次の3章でも活用していきます。

まとめ

2-6では、第2章で学んだsudo・su -・chmod・chown・chgrpを組み合わせ、共有ディレクトリを実際に作って使い、権限による成功と失敗の両方を体験しました。このページで叩けるようになったコマンドを一覧にまとめます。

コマンド何をするか覚え方
sudo mkdir /home/<名前>/home直下に新しいディレクトリを作るrootの領域なのでsudo必須
sudo chown <所有者>:<グループ> <パス>所有者とグループを同時に設定する2-5の総まとめ
chmod 770 <パス>所有者とグループに全権、その他は不可にする身内だけの共有部屋
su - yumiyumiとして完全にログインし直す2-3の総まとめ
chmod 700 <パス>所有者以外を完全に締め出すグループも含めて閉じる
sudo rm -r <パス>ディレクトリを中身ごと再帰的に削除する片付けの最終手段、パスは要確認

第2章「ユーザーと権限 ― yumiを迎える」はこれで完了です。次の第3章「3-1. nanoでファイルを編集する」からは、テキストエディタを使ってファイルの中身そのものを編集する技術に入っていきます。

脚注 ─ 用語解説
  1. 770(数字指定パーミッション) … 所有者・所有グループにフルアクセス(rwx)を与え、その他は完全に締め出す設定。共有フォルダの定番。↩
  2. 700(数字指定パーミッション) … 所有者のみフルアクセス、所有グループを含む他の全員を締め出す最も閉じた設定の1つ。↩
  3. rm -r(再帰的削除) … ディレクトリとその中身をまとめて削除するコマンド。対象パスを誤ると大きな被害につながるため、実行前によく確認する。1-3参照。↩
  4. グループ権限の反映タイミング … usermod -aGで追加したグループ所属は、既存のログインセッションには反映されない。有効にするには再ログイン(su -のやり直しなど)が必要。↩
  5. Permission denied … 権限不足によって操作が拒否されたときのエラー。同じユーザー・同じ場所でも、権限設定が変われば結果が変わる。↩