ユーザーとグループの概念

同じサーバーに 3 人で入ると、誰のファイルか分からなくなる

Linux は 1 台のマシンに複数の人が同時にログインして作業する前提で作られています。だから「このファイルは誰のものか」「誰なら触ってよいか」を OS 自身が覚えています。その覚え方の単位が、ユーザーとグループです。

人が増えるたびにファイル 1 つずつへ「田中さんも OK」「佐藤さんも OK」と書き足していくと、すぐ破綻します。そこで Linux は、人をグループにまとめ、ファイルにはグループの名前だけを結び付けます。新しいメンバーが来たらグループに入れるだけで済み、ファイル側は 1 つも書き換えません。

1 人が複数のグループに入れる

bob のように 2 つのグループへ同時に所属できます。主たる所属先をプライマリグループ、追加の所属先をセカンダリグループと呼びます。新しく作ったファイルの所有グループになるのは、プライマリのほうです。

自分がどこに所属しているかを見る

whoami はユーザー名だけ、groups は所属グループの名前だけを返します。番号まで含めて全部見たいときは、id にユーザー名を渡します。

uid が本人の番号、gid がプライマリグループ、groups が所属の全部です。ここに sudo が入っているかどうかが、管理者としての作業ができるかどうかの分かれ目になります。

番号は 0 が root、1 から 999 まではシステムの予約席、1000 以降が人間のユーザー、という並びが慣習です。ユーザー名とこの番号の対応は /etc/passwd に、グループ名と番号の対応は /etc/group に書かれています。

アプリにも専用のユーザーを与える

nginx や postgres のように、人ではないサービスにも専用のユーザーが作られます。Web サーバーが乗っ取られても、そのユーザーが触れる範囲までしか壊せないようにするためです。管理者用のユーザーで動かしていると、1 つの穴がマシン全体の被害に直結します。

既存のユーザーをグループへ追加するときは、-a を必ず付けます。

解説

-a を落として usermod -G developers bob と書くと、bob の所属が developers 1 つだけに置き換わります。それまで入っていた sudo グループから外れて管理者作業ができなくなる、という事故の定番です。