sudoコマンド｜管理者の権限でコマンドを実行する

書式

sudo コマンド

そのコマンドだけを管理者（root）の権限で実行します。

まず打ってみる

いまのユーザーは user です。

$ whoami
user

システムのログは、普通のユーザーには読めません。

$ cat /var/log/auth.log
cat: /var/log/auth.log: Permission denied

sudo を付けると読めます。

$ sudo cat /var/log/auth.log
Sep  7 09:00:01 webterm sshd[456]: Accepted publickey for user from 192.168.1.10
Sep  7 09:14:22 webterm sudo:     user : COMMAND=/usr/bin/systemctl restart nginx

このログ自体が、誰が sudo で何を実行したかの記録です。

何が変わるのか

変わるのはそのコマンドを実行するユーザーだけです。

$ sudo whoami
root
$ whoami
user

sudo whoami は root と答え、次の whoami は user に戻っています。 権限が上がるのは1コマンドのあいだだけ、というのが sudo の考え方です。

触れないものに触る

配置先のディレクトリが root のものだと、コピーもできません。

$ cp index.html /var/www/html/
cp: cannot create '/var/www/html//index.html': Permission denied
$ sudo cp index.html /var/www/html/
$ ls -l /var/www/html
total 4
-rw-r--r--   1  root  root     15  Sep  7 17:17  index.html

sudo で作ったファイルは root のものになります。 あとで自分が編集したいものなら、sudo chown user:user ファイル で持ち主を戻しておきます。

サービスの操作も同じです。

$ sudo systemctl restart nginx
$ systemctl is-active nginx
active

リダイレクトには効かない

sudo のいちばんの落とし穴です。

$ echo '10.0.0.1 db' >> /etc/hosts
zsh: permission denied: /etc/hosts

sudo echo '10.0.0.1 db' >> /etc/hosts と書いても結果は同じです。 >> を処理するのはシェルであって、sudo が届くのは echo の部分だけだからです。 書き込む側を root にするために、tee を使います。

$ echo '10.0.0.1 db' | sudo tee -a /etc/hosts
10.0.0.1 db
$ cat /etc/hosts
127.0.0.1 localhost
10.0.0.1 db

sudo tee -a は、設定ファイルに1行足すときの定番です。

実務での使いどころ

sudo は、自分のものではないものを触るときに打つコマンドです。

つまずきやすいところ

sudo が届くのはコマンドまでです。 リダイレクト（> >>）、パイプの右側、~ の展開などはシェルの仕事です。 「sudo を付けたのに Permission denied」の大半はこれです。

sudo で作ったファイルは root のものになります。 あとから自分で編集できずに困ることがあります。 ls -l で持ち主を確かめ、必要なら chown で戻してください。

打つ前に、対象をもう一度読んでください。 sudo を付けた瞬間、システムのファイルにも手が届きます。 rm -rf のような取り返しのつかない操作は、パスを指差し確認してから実行してください。