専用ユーザーで動かす

root で全部やるのをやめる

ここまでの作業は、すべて root で行ってきました。学習の間は手早くて助かりますが、運用に持ち込むと危険です。root は何でもできてしまうので、打ち間違いひとつでシステム全体を壊せます。乗っ取られたときの被害も、そのまま全体に及びます。

考え方はひとつです。その仕事に必要な権限だけを渡す。これを権限最小の原則と呼びます。2章で見た nginx の worker が www-data で動いていたのも、まさにこれでした。

この章では、サイトを更新するための専用ユーザーを作り、そのユーザーでデプロイができる状態を整えます。

ユーザーを作る

-m は、そのユーザーのホームディレクトリを作る指定です。付け忘れると /home/deploy が無いまま作られ、次の回で作る鍵の置き場所に困ります。-s /bin/bash は、ログインしたときに使うシェルの指定です。

作られたかどうかは、ユーザーの定義が並ぶファイルで確かめられます。

コロンで区切られた並びの中に、ホームディレクトリとシェルが見えます。

書き込める場所を絞って渡す

専用ユーザーを作っただけでは、サイトのファイルを更新できません。/var/www/mysite の持ち主は root だからです。

ここで安易に chmod 777 としないでください。誰でも書き換えられる状態は、権限最小とは正反対です。持ち主のほうを変えます。

-R はディレクトリの中身まで含めて変える指定です。これで deploy はサイトを更新でき、それ以外の場所には手を出せません。

配信する側は読めればいい

ここで気をつけるのは、nginx の worker が www-data で動いていることです。持ち主を deploy にしても、他のユーザーへの読み取りが許されていれば配信は続きます。

末尾の r-x が、持ち主以外にも読み取りと移動を許している部分です。ここまで落としてしまうと、サイトが 403 を返し始めます。持ち主を変えたら、必ず配信が続いているかを確かめてください。

別のユーザーとしてコマンドを試す

作ったユーザーで実際に動かせるかは、切り替えて確かめます。

su - deploy -c は「deploy として、このコマンドを1つ実行する」という書き方です。成功すればファイルができ、権限が足りなければ拒まれます。設定した権限が意図どおりかを、思い込みではなく実行で確かめられます。

手を動かす

デプロイ用のユーザーを作り、サイトのディレクトリを渡します。そのユーザーで実際に書き込めること、そして配信が止まっていないことを両方確かめます。