このサイトは、もともと作者の自分用メモとして書き始めたものです。書いてあることが全て正しいとは限りません。他の文献、オフィシャルなサイトも確認して、自己責任にて利用してください。

Sudo

あまりにも基本的なツールだからなのか、世の中では「いまさら聞けない」状態になっていてあまり良いドキュメントがなかったので、これをまとめることにした。ちなみに sudo の読み方だが、オフィシャルサイトの FAQ によると、「我々は 『スードゥー (soo-doo)』 と呼んでいるが、"pseudo" と同じ読み方 (つまり 『スード』) も一般的だ」とある。

設定

sudo の設定ファイルが /etc/sudoers。RedHat 系では PAM でも一部制御されており、/etc/pam.d/sudo ファイルも動作に影響を与えるのだが、ここでは sudoers ファイルについてのみ述べる。

sudoers ファイルを編集するには、ファイルを直接エディタで開くのではなく、root 権限で、

root# visudo

とコマンドする。すると sudoers がテンポラリファイルにコピーされて、コピーが vi で開かれる (エディタプログラムの変更は後述)。そして、編集して保存すると、それが本来のファイルに書き戻される。同時編集防止のロック機能も備え、保存時には構文エラーチェックも行われるので、必ず visudo 経由で編集するよう心掛けるべきだ。

sudoers ファイルは、大別すると

• User定義
• Alias定義
• Defaults定義
• その他のディレクティブ

の 4つから成る。以下に、それぞれの書き方や設定のポイントを述べる。

User定義

通常は sudoers ファイルの最後に書くものだが、これを知っておかないと次項からの説明が何のことやら分からないので、最初に説明する。ユーザ定義こそが、「誰が誰として何をできるか」を制御する sudoers のメインであり、後述の Alias定義などは (スクリプトに喩えれば) メイン部分で使用するための変数設定のようなものだ。

User定義文の書式

User定義文は、下記のフォーマットを採る (Tag については後述する)。

User Host = (RunasUser) [Tag:] Command

噛み砕いて日本語で書いてみると；

誰が どのホスト上で = (誰として) [Tag:] 何を実行できるか

ただし、上の表記は単純化したものだ。実際には各要素を一度に複数指定することができる (この柔軟性が逆に sudo の敷居を高くしている！)。複数指定を加味した上で、man などで使われるコマンド表記法に近いカタチで書くとこうなる；

User[,User[,..]] Host[,Host[,..]] = \
  (RunasUser[,RunasUser[,..]]) [Tag:[Tag:[..]]] Command[,Command[,..]] \
[,(RunasUser..)..] \
              [,Host[,Host[,..]] = ..] \
              [,Host....]

苦しくなって色分けまでしてみたけれど、わっかるかなぁ。sudo の man の EBNF 表記よりは分かりやすいと思うのだが...

書き方についての幾つかポイント；

• User や Host、RunasUser、Command は、エイリアスを使って指定することもできる。その方がきれいだし確実。
• `,' や `=' や `(' や `)' の前後のスペースは、あってもなくても複数でも構わない。
• ただし、Tag を複数指定したい時には、タグとタグとの間にスペースを入れてはいけない。`NOPASSWD:SETENV:' といった具合にくっつける。コマンド群毎に Tag を切り替えることもできるが、タグまで網羅すると判読不能になりそうだったので詳しくは次項で。
• 行が長くなる場合には、シェルスクリプト同様に改行直前にバックスラッシュを付ければ論理上の 1行と解釈される。

Tagについて

sudo 1.7.2p1 でのタグには以下の 3種類がある。(NO)PASSWD:以外の 2つは RHEL/CentOS 4 の sudo にはまだない。最新の sudo ではこの他に (NO)LOG_INPUT:, (NO)LOG_OUTPUT: というタグもあるようだ。

タグは、User定義文の Command 部分で使用し、タグが出現してから次のタグが出現するまでのコマンド群が効果を受ける。例えば、

ADMINS MYBOX = (IMPORTANT) STORAGE, NOPASSWD: SOFTWARE,\
                          SETENV:NOPASSWD: PERFORMANCE

と定義した場合、「コマンドエイリアス STORAGE に属するコマンドはタグ修飾なし、SOFTWARE はパスワードなしで実行でき、PERFORMANCE は環境変数保持が可能で且つパスワードなしで実行できる」となる。基本書式のところでも少し触れたが、タグを「且つ」のつもりで使用するところは、`SETENV: NOPASSWD:' という風にスペースを挟むと意味が違ってしまう。

Alias定義

エイリアスは、幾つかのコマンドやユーザをまとめて指す変数のようなものだ。エイリアスには、Host_Alias, User_Alias, Runas_Alias, Cmnd_Alias の 4つがある。

共通の記述ルールは、

Alias_Type NAME = item, item, item, .. 

ここで、いわば変数名である NAME は、大文字アルファベットで始まり、大文字アルファベット, 数字, アンダーバー(`_') だけから成っていなければならない。その他、特別なエイリアスとして、全てにマッチする `ALL' がある。ALL は予約語であり、ALL というエイリアスを再定義しようとしても無理。

ふと疑問が起こり、別々のエイリアスタイプに同じ名前のエイリアスを定義してみたところ、それらはちゃんと区別されることが分かった。例えば、User_Alias として定義した ADMINS と Runas_Alias で定義した ADMINS は、別のものとして扱われる。

Host_Alias

「どのホスト上で」のホストを格納するエイリアス。経験として、ユーザ定義文で自機ホスト名を直接書いてもうまくいかなかった場合があったため、以後は自機ホスト名を必ず Host_Alias に入れて使う習慣になっている。ただし、Host_Alias が何の役に立つのか飲み込める機会に出会えていない。sudo が某かのネットワークポートをリッスンしているわけでもないし、例えば sudo 経由で ssh を使って他機に乗り込んでも、ローカル上に書いた他機のホスト名や IP が効果を発揮するわけではない。この機能はおそらく、sudoers ファイルを共有ディスクに置き NFS などで複数のホストから参照している場合にのみ意味があるのだろう (※)。よって、これに関して書式云々について書くのはやめる。代わりに、ちょっと気付いたことを幾つか挙げる。

※ NFS共有に sudo 設定ファイルを置くには： sudo の設定ファイルは /etc/sudoers と決まっている。ソースコードに手を入れてコンパイルし直せば変えられるだろうが、そんなことをしなくても済む仕組みがある。#include と #includedir という特殊ディレクティブだ。それについては「その他のディレクティブ」で述べる。

ポイント1

ホストエイリアスの中身には、ホストネーム, IPアドレス, ネットワークアドレス, ネットグループ または他のホストエイリアス が使えるとマニュアルにはある。ホストネームで自機を指定する場合には、hostname コマンドがドメイン付きの FQDN を返す環境ならば、`alpha.hoge.cxm' のように FQDN で書くのがよさそうだ。ただし、hosts ファイルで alpha というエイリアス名が解決できれば (たいていはできるだろう)、`alpha' だけでも通用する。IPアドレスで書いた場合、sudo はネットワークインターフェースのパラメータを照会すると書かれている。ネットマスクなしで IPアドレスかネットワークアドレスを書いた場合、その数値が自機の持っているいずれかのネットワークインターフェースに合致すればそこからネットマスクを求めようとする。とすれば、IPアドレスで自機を示そうとする時に最も理に適った書き方は、`192.168.1.10/32' という指定だと思われる。ネットマスクは 255.255.255.255 式でも良い。

ポイント2

上記に付随するが、自機を示すつもりで `localhost' と書くのは間違い。sudo では localhost がヒットすることはない。あるとすれば、自機のホストネームが文字通り localhost という名前の時だけだ。

User_Alias

「誰が」のユーザやグループを格納するエイリアス。中身には以下のものが指定できる。

いずれも、前に `!' を付けて「～でない」の意味にすることもできる。例えば、

root# usermod -G www taro

としてユーザ taro を副グループ www に属させてあるとしよう。そこで、www グループを指す User_Alias "WEBMNGERS" から taro だけを仲間はずれにしたい場合のユーザエイリアス定義は；

User_Alias WEBMNGERS = %www, !taro 

Runas_Alias

「誰として」のユーザやグループを格納するエイリアス。定義規則は User_Alias と同じ。違いは、内容に含めることのできる別エイリアスが Runas_Alias であることくらい。

Cmnd_Alias

「何ができるか」を格納するエイリアス。中身に指定できるものは、大まかに言うと；

• コマンドファイル名
• sudoedit
• ディレクトリ
• 他の Cmnd_Alias

となるが、少々複雑なので以下それぞれについて述べる。

コマンドファイル名および sudoedit

単純な定義例としては、

Cmnd_Alias STORAGE = /bin/mount, /bin/umount, /sbin/shutdown 

右辺に入るものは、コマンドファイルの実体でなければならないという制限はない。シンボリックリンクでもシェルスクリプトでも動作が成り立つ。上記のようにコマンドファイルだけを指定すると、どんな引数も受け入れられる。引数を制限したい場合には、

/sbin/shutdown -h *

のように引数を限定することもできる。次のカンマ `,' が現れるまでがひとつのコマンド指定と解釈されるので、このようにスペースを含む時でもクォーテーションで囲む必要はない。逆に、引数の要素としてカンマを使いたい場合にはバックスラッシュ `\' でエスケープする必要がある。その他にエスケープの必要な文字としては、`@!=:()\' がある。

引数の使用を一切許可したくない時には、

/bin/date ""

のように定義する。最初の例で用いたように、ワイルドカード (正規表現ではなく POSIXグロブ) も使える；

ワイルドカードの例：

Cmnd_Alias STORAGE_MIN = /sbin/fdisk -l /dev/[a-z][a-z][a-z], /sbin/parted

フルパスを書かなくてよい特別なものに、sudoedit がある。「Tag について」でも少々触れたが、sudoedit は sudo 経由で使うことを考慮して書かれた一種の vi クローンだ。編集中に `:sh' と打つなどしてシェルエスケープ機能を使用する際、通常の vi や vim とは異なり「誰として」の権限のシェルでなく「誰が」つまり元のユーザのシェルにしか入れないようにできている。実際に sudoedit を開始するには `sudoedit file ' と `sudo -e file ' というふた通りの実行方法がある。sudoedit を Cmnd_Alias に登録する際には、他のコマンドファイル同様に引数を制限することもできる。

その他の考慮事項：

コマンド実行時のパスの省略について

実際にコマンドする時に `sudo mount ...' のようにパスが省略できるかどうかは、「誰が」の環境変数 PATH にそのコマンドの在処が含まれているかどうかによる。「誰として」の環境の PATH ではない。

シェルの実行を許可することについて

sudo には、`sudo -i' あるいは `sudo -s' と打つと「誰として」のユーザの対話シェルに入れる機能がある。この機能を利用するには、sudoers で「誰として」実行できるコマンドリストにシェルを含めておかなければならない。シェルは、/etc/passwd で定義されているそのユーザのデフォルトシェル、例えば /bin/bash だ。ただし、`sudo -i' の場合は、環境変数 SHELL の値の方が優先されるので、`env SHELL=/bin/sh sudo -s' という風にコマンドすれば別のシェルを起動することもできる。それをやりたいのなら、この例で言えば /bin/sh を sudoers で許可しておく。しかし...

一般ユーザで何か大それたことを実行する時に `sudo sh ...' というコマンド例が書いてあるのを世の中の技術系ブログなどで見かけるが、sudo でのシェルの実行を許可しなければならない必然性に筆者は疑問を持っている。シェルが実行できるということは、sh の後にどんなシェルスクリプトでもコマンドでも与えて実行できるということだ。利便性よりセキュリティリスクのほうが大きい。シェル以外でも、不特定のファイルを対象とするようなジェネリックなコマンド (ls, cp, mv, chmod...等々) を許可するのは、どうかと思う。

シェルスクリプトの実行を許可することについて

Cmnd_Alias にシェルスクリプトを指定することはできる。ただし、他のユーザ (特に root) の権限でシェルスクリプトを実行することを許可するのは SetUID するのと同じで、パーミッションのページ にも書いたように、安全なこととは言えない。

ALL but ... の罠

User定義で、「何でもできる、ただし～は禁止」のつもりで、こういうこと

ADMINS MYBOX = (root) ALL, !SHELLS

をするのは良くない。実際に規制するのは相当難しい。ユーザエイリアス ADMINS に属する人は、好きな実行ファイルを別の名前でコピーすれば実行できるし、vi や vim などエディタのシェルエスケープ機能を利用すれば root のシェルだって実行できる。じゃあ vi も vim も禁止だ、emacs も、cp も chmod も...とキリがなく、結局無理。

ディレクトリ

コマンドファイル名にあたる部分がスラッシュ `/' で終わっていると、ディレクトリを指定しているとみなされる。ディレクトリを指定すると、そのディレクトリ直下の実行ファイル全てがそのエイリアスの対象となる。サブディレクトリ下のファイルは含まれない。ディレクトリに関しても前述のコマンドファイルの場合と同様に、他のディレクトリへのシンボリックリンクでも sudo は頓着しないし、ディレクトリ下のファイルがシェルスクリプトでもシンボリックリンクでも構いはしない。コマンドファイルと同様、ワイルドカードを使った指定もできる。ただし、スラッシュ `/' はワイルドカードにヒットしない。

もちろん、コマンドファイルの否定を組み合わせて、「ただし～はダメ」という設定はできる。例えば、

Cmnd_Alias LOCALBIN = /usr/local/bin/, !/usr/local/bin/ls

許可ディレクトリのパーミッションには注意が必要だ。直下に誰でもファイルやシンボリックリンクを作れる状態だと、やりたい放題になってしまう。まあ、結論から言って、ディレクトリによる指定は上手に使うには難しい。

Defaults定義

sudo の挙動を、あらゆる「誰が」や「誰として」のユーザに対してや、特定のユーザやホストなどに関して一括してコントロールするディレクティブ。基本書式は；

Defaults[:User|>RunasUser|!Cmnd|@Host] Parameter[,Parameter[,..]]

`Defaults Parameter ' のように定義すれば、グローバルな規定となる。かたや、例えば `Defaults:ADMINS Parameter ' のように書くとユーザエイリアス ADMINS に対する規定となり、グローバルな規定をオーバーライドする。同じタイプのエイリアスなら、`Defaults:ADMINS,BACKUPS Parameter ' といった具合にまとめて定義することも可能。

Parameter 部は、パラメータの種別によって、`Param = Value ' のように値を採るものと、採らないものがある。前者では、グローバルな規定に対して値を追加 (`+=') したり一部を無効化する (`-=') 書き方もできる。後者の種類のものを無効化したい時には `!Parameter ' のように書く。以下に、興味を惹くパラメータだけ挙げる。

記述例：

Defaults    env_reset, !env_editor, editor=/usr/bin/vim

下記のようにパラメータ毎に別々に唱えてもいい；

Defaults    env_reset
Defaults    !env_editor
Defaults    editor=/usr/bin/vim

ユーザエイリアス ADMINS に許可するコマンドは全て、パスワード不要にし、環境変数の保持も可能にするなら、

Defaults:ADMINS    !authenticate, setenv

つまり上記は、User定義で

ADMINS    MYBOX = (ALL) NOPASSWD:SETENV: STORAGE, SOFTWARE, ...

などと書くよりすっきりする。

NOEXEC: タグと同等の制限を Defaults定義でまとめて掛ける例；

Defaults!EDITORS,PAGERS    noexec

グローバルな保持する環境変数のリストに、ユーザエイリアス ORACLE の時だけ更に変数を追加する例；

Defaults    env_keep = "COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR \
                        LS_COLORS MAIL PS1 PS2 QTDIR USERNAME \
                        LANG LC_ADDRESS LC_CTYPE LC_COLLATE LC_IDENTIFICATION \
                        LC_MEASUREMENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC \
                        LC_PAPER LC_TELEPHONE LC_TIME LC_ALL LANGUAGE LINGUAS \
                        _XKB_CHARSET XAUTHORITY"
 
Defaults:ORACLE  env_keep += "ORACLE_HOME ORACLE_SID"

その他のディレクティブ

#include と #includedir

/etc/sudoers ファイルの中で '#include /PATH/TO/FILE ' を書いておけば、そのディレクティブが現れたところで別の設定ファイル /PATH/TO/FILE が読み込まれる。大元の /etc/sudoers ファイルには #include 文だけを書いておき、/PATH/TO/ をNFSマウントで作っておけば、設定の全てをホスト間で共有することも可能だ。

`#includedir /PATH/TO/DIRECTORY ' の場合は、そのディレクトリ下のファイルがファイル名で文字列ソートされた順で読まれる。#includedir の場合のみ、インクルードディレクトリ下のファイルにはファイル名規制があり、`~' で終わるファイルと、ドットを含むファイル (頭であれ途中であれ) は読んでくれない。

実際に試してみると、どちらにしろ、別体設定ファイルを置くディレクトリのパーミッションは root:root の 750 でなくはならないようだ。700 だと読み込めない。なお、visudo で /etc/sudoers を書き換えると、その中で #include や #includedir で指してあるファイルも「編集するか？」と訊いてくる (逆に、それを断る方法が分からない...)。インクルード先のファイルを決め打ちで編集したい時は `visudo -f /PATH/TO/FILE ' とコマンドすればいい。インクルードした設定ファイルから更に #include や #includedir することも可能だが、ループに注意しなければならない。無限ループ防止のため、ネストは 128段階に制限されている。

sudoの実行

興味のあるコマンドラインオプションだけ挙げる。

sudoコマンドオプション