名前

sudo, sudoedit - コマンドを他のユーザとして実行する

書式

sudo -h | -K | -k | -V
sudo -v [-AknS] [-g group] [-h host] [ -p prompt] [-u  user]
 
sudo -l [-AknS] [-g group] [-h host] [ -p prompt] [-U  user] [-u user] [command]
 
sudo [-AbEHnPS] [-C num] [-g group] [ -h host] [ -p  prompt] [-r role] [-t  type] [-u user] [ VAR=value] [-i | -s] [command]
 
sudoedit [ -AknS] [-C num] [-g group] [ -h host] [ -p prompt] [-u  user] file ...

説明

sudo を使用すると、許可されたユーザが、セキュリティポリシーの設定の範囲内で、 スーパーユーザや他のユーザに変身して、 command を実行することが可能になる。 セキュリティポリシーへの問い合わせは、ユーザ名によって行われるが、 そのユーザ名を決めるのは、 sudo を実行するユーザの実ユーザ ID であって、 実効ユーザ ID ではない。
sudo はセキュリティポリシーと入出力のロギングについて、プラグイン方式をサポートしている。 従って、サードパーティは、 sudo フロントエンドとシームレスに協働するポリシー・プラグインや入出力ロギング・プラグインを、 独自に開発して配布することができる。 デフォルトのセキュリティポリシーは sudoers であり、その設定は、 /etc/sudoers ファイル、もしくは LDAP を通して行われる。 詳細については、「プラグイン」セクションを参照していただきたい。
セキュリティポリシーは、あるユーザに sudo を使用する権限があるかどうか、 あるとすれば、どんな権限を持っているかを決定する。 セキュリティポリシーは、ユーザにパスワードや他の認証方法を使って、 本人であることを証明するように要求することができる。 認証が必要な場合、ユーザが自分のパスワードを、 設定によって変更可能な制限時間内に入力しないと、 sudo は時間切れで終了する (訳注: sudo はデフォルトでは、root や変身対象ユーザのパスワードではなく、 sudo を実行するユーザ本人のパスワードを要求する)。 この制限時間はポリシー次第であり、 sudoers セキュリティポリシーの場合、 パスワード・プロンプトがタイムアウトするまでのデフォルトの時間は、5 分間である。
セキュリティポリシーは、一定時間内ならユーザが認証なしで sudo を何度も実行できるように、認証情報の一時保存 (credential caching) をサポートしてもよい。 sudoers ポリシーでは、sudoers(5) で変更されないかぎり、認証情報を 5 分間保持する。 ユーザは sudo に -v を付けて実行することで、 command を実行しないでも、保存された認証情報を更新することができる。
sudoedit というコマンド名で起動するのは、 sudo に -e オプション (下記参照) を付けて実行するのと同じである。
セキュリティポリシーは、ユーザが sudo を使おうとして成功した場合も失敗した場合も、それをログに記録することができる。 入出力プラグインが設定されている場合は、 sudo 経由で実行するコマンドの入出力もログに残すことができる。
オプションとして以下のものが使用できる。
-A, --askpass
通常 sudo がパスワードを要求するとき、 パスワードはユーザが使用している端末から読み込まれる。 -A (askpass) オプションを指定すると、 ヘルパー・プログラム (グラフィカルなものでもよい) が実行され、ユーザのパスワードを読み込んで、それを標準出力に書き出す。 環境変数 SUDO_ASKPASS が設定されているときは、 それがヘルパー・プログラムのパスになる。 それ以外の場合は、sudo.conf(5) に askpass プログラムを指定している行が存在すれば、 その値が使用される。一例を挙げよう。 
 

    
# askpass ヘルパー・プログラムのパス
Path askpass /usr/X11R6/bin/ssh-askpass

 
利用できる askpass プログラムがないと、 sudo はエラーメッセージを出して、 終了する。
-a type, --auth-type=type
/etc/login.conf で使用可になっていれば、ユーザを認証する際に指定された BSD の認証方法 type を使用する。システム管理者は、 /etc/login.conf に "auth-sudo" エントリを追加することで、 sudo 専用の認証方法のリストを指定することができる。このオプションは、 BSD 認証をサポートするシステムでのみ使用できる。
-b, --background
指定されたコマンドをバックグラウンドで実行する。 sudo 経由で起動したバックグラウンド・プロセスは、 シェルのジョブ制御を使って操作できないことに注意していただきたい。 バックグラウンドモードでは、ほとんどの対話的なコマンドがうまく動かないだろう。
-C num, --close-from=num
コマンドを実行するに先立って、num 以上の番号のファイル・ディスクリプタをすべてクローズする。 3 未満の値は指定できない。デフォルトでは、コマンドを実行する際に、 sudo は、標準入力、標準出力、標準エラー以外の、 オープンしているすべてのファイル・ディスクリプタを閉じることになっている。 セキュリティポリシーは、ユーザによるこのオプションの使用を制限することができる。 sudoers ポリシーが -C オプションの使用を許可するのは、 管理者が closefrom_override オプションを有効にしているときのみである。
-c class, --login-class=class
指定されたログインクラス class のリソース・リミットとスケジューリング優先度で、 コマンドを実行する。引き数 class に使用できるのは、 /etc/login.conf で定義されたクラス名か、単独の '-' 文字のどちらかである。 class が - ならば、変身対象ユーザのデフォルトのログインクラスが使用されることになる。 それ以外の場合は、コマンドをスーパーユーザ (ユーザ ID が 0) として実行するか、 あるいは、すでにスーパーユーザとして実行しているシェルから sudo を実行するかのどちらかでなければならない。 実行されるコマンドがログイン・シェルである場合は、 umask や環境変数といった /etc/login.conf の他の設定も、 存在すれば適用されることになる。 このオプションは BSD ログインクラスを採用しているシステムでのみ有効である。
-E, --preserve-env
現在の環境変数をそのまま保持するのがユーザの意向だと、セキュリティポリシーに指示する。 ユーザが環境を保持する許可を持っていない場合は、 セキュリティポリシーがエラーを返すことになるだろう。
-e, --edit
何らかのコマンドを実行するのではなく、1 個以上のファイルを編集する。 セキュリティポリシーの参照では、コマンドのパス名の代わりに "sudoedit" という文字列が使用される。 セキュリティポリシーによってユーザに権限があることが認められると、 次のことが順番に行われる。
1.
編集対象のファイルのコピーをテンポラリファイルとして作成する。 テンポラリファイルのオーナーは sudo を起動したユーザである。
2.
セキュリティポリシーによって指定されたエディタを起動して、 テンポラリファイルを編集する。 sudoers ポリシーでは、環境変数 SUDO_EDITOR, VISUAL, EDITOR を (この順番で) 使用する。 SUDO_EDITOR, VISUAL, EDITOR のどれも設定されていない場合は、 sudoers(5) の editor オプションにリストされたプログラムのうち、 最初のものが使われる。
3.
編集作業がすむと、テンポラリファイルをオリジナルのファイルにコピーして、 テンポラリファイルを消去する。
 
編集する権限のないファイルを編集できないようにするため、 セキュリティポリシーによって明示的に許可されていないかぎり、 以下の制限が行われる。
•
シンボリックリンクの編集は許可しない (バージョン 1.8.15 以上)。
•
sudo を実行するのが root であるときを除いて、 編集するファイルのパス中にシンボリックリンクがある場合、 そのリンクの親ディレクトリが sudo を実行するユーザにとって書き込み可能ならば、 リンクをたどらない (バージョン 1.8.16 以上)。
•
sudo を実行するのが root であるときを除いて、 ファイルが sudo を実行するユーザにとって書き込み可能なディレクトリにある場合、 そのファイルの編集を許可しない (バージョン 1.8.16 以上)。
 
ユーザがデバイス・スペシャルファイルの編集を許可されることは絶対にない。
 
指定されたファイルが存在しない場合は作成する。ここで注意すべきは、 sudo によって実行されるコマンドの大部分と違って、 -e でエディタが実行されるときは、 sudo を起動したユーザの環境が、 変更を受けずに使われるということだ。 何らかの理由で sudo が編集した内容でファイルを更新できないときは、 ユーザに警告を発し、編集した内容をテンポラリファイルに保存することになる。
-g group, --group=group
コマンドを実行するとき、 プライマリ・グループをパスワード・データベースの変身対象ユーザの項目で指定されているものではなく、 group に設定する。group は、グループ名でもよく、'#' 記号にグループ ID 番号 (GID) を続けたものでもよい (たとえば、GID 0 なら　#0)。 GID としてコマンドを実行する場合、ほとんどのシェルでは、 '#' をバックスラッシュ ('\') でエスケープする必要がある。 なお、 -u オプションが指定されていない場合、コマンドは sudo を起動したユーザの資格で実行される。いづれにしろ、 プライマリ・グループが group に設定されることに変わりはない。 (訳注: -g オプションを使用するには、 sudoers ポリシーの場合なら、 sudoers ファイルのユーザ設定で、 変身対象となるグループを設定しておく必要がある。詳細については、 sudoers(5) のマニュアルの該当個所を参照していただきたい。)
-H, --set-home
HOME 環境変数を、パスワード・データベースの変身対象ユーザの項目で、 ホームディレクトリとして指定されているものに設定するように、 セキュリティポリシーに要求する。 ポリシーによっては、それがデフォルトの動作になっていることもある。
-h, --help
簡単なヘルプメッセージを標準出力に表示して、終了する。
-h host, --host=host
セキュリティポリシー・プラグインがリモート・コマンドをサポートしているなら、 指定された host でコマンドを実行する。 sudoers プラグインは、現在のところ、 リモート・コマンドの実行をサポートしていないことに注意していただきたい。 このオプションを -l オプションと一緒に使えば、 リモート・ホストにおけるユーザの権限のリストを得ることができる。 (訳注: このオプションについは、sudo_plugin(5) のマニュアルの "Remote command execution" セクションもご覧いただきたい。 そちらの説明が詳しい。)
-i, --login
パスワード・データベースの変身対象ユーザの項目でログイン・シェルとして指定されているシェルを実行する。すなわち、 .profile や .login といったログイン用のリソース・ファイルが、 シェルによって読み込まれることになる。コマンドを指定すると、 それがシェルに渡され、シェルの -c オプションを使って実行される。 コマンドを指定しない場合は、対話的シェルが起動される。 sudo は、 シェルを実行する前に、変身対象ユーザのホームディレクトリに移動しようとする。 コマンドの実行は、ユーザが普通にログインしたときの環境とほぼ同じ環境で行われる。 sudoers ポリシーを使用している場合に、 -i オプションがコマンドの実行環境にどんな影響を与えるかについては、 sudoers(5) のマニュアルの「コマンド環境」セクションに説明がある。
-K, --remove-timestamp
-k オプションに似ているが、ユーザの保存された認証情報を完全に消去してしまう点と、 コマンドや他のオプションと組み合わせて使えない点が異なっている。 このオプションはパスワードを要求しない。すべてのセキュリティポリシーが、 認証情報の一時保存をサポートしているわけではない。
-k, --reset-timestamp
コマンドを伴わずに使用した場合は、ユーザの保存された認証情報を無効にする。 言い換えると、次回 sudo を実行するときに、 パスワードが要求されるということだ。このオプション自体は、 パスワードを要求しない。このオプションが追加されたのは、 ユーザが .logout ファイルで、 sudo をパスワードなしで実行できる期間を終了させることができるようにするためである。 コマンドや、パスワードを必要とするような他のオプションと組み合わせて、 このオプションを使用すると、 sudo がユーザの保存された認証情報を無視することになる。 その結果、 sudo は (セキュリティポリシーがパスワードを要求するならば)、 プロンプトを出して、パスワードを要求する。 このとき、ユーザの保存された認証情報の更新は行われない。 すべてのセキュリティポリシーが、認証情報の一時保存をサポートしているわけではない。
-l, --list
コマンドを指定しない場合は、sudo を実行しているユーザ (あるいは、 -U オプションで指定したユーザ) が、現在ログインしているホストで許可されている (及び、禁じられている) コマンドのリストを表示する。 このオプションを複数回指定すると、 セキュリティポリシーが詳細な出力形式をサポートしていれば、 長い方のリスト形式が使用される。 コマンドを指定した場合は、その実行がセキュリティポリシーによって許可されていれば、 コマンドの絶対パスが表示される。 コマンドラインでコマンドに引き数まで指定すると (訳注: その引き数が許可されていれば)、それも一緒に表示される。 指定したコマンドが許可されていない場合は、 sudo はステータス 1 で終了することになる。
-n, --non-interactive
プロンプトを出してユーザに入力を求めることを一切しない。 コマンドを実行するのにパスワードが必要な場合、 sudo はエラーメッセージを出して、終了することになる。
-P, --preserve-groups
sudo を実行するユーザの所属グループのリストを、変更せずにそのまま使用する。 デフォルトでは、 sudoers ポリシーの場合、所属グループは初期化されて、 変身対象ユーザが所属しているグループのリストが使われることになっているのである。 とは言え、実グループ ID と実効グループ ID が、 変身対象ユーザと同一になるようにセットされる点には変わりがない。
-p prompt, --prompt=prompt
パスワードプロンプトに好みの文字列を使用する。文字列には、 エスケープシーケンスが使用できる。 sudoers では、 以下のパーセント ('%') エスケープシーケンスをサポートしている。
%H
ドメイン名を含むホスト名に展開される (マシンのホスト名が完全修飾名であるか、 sudoers(5) で fqdn オプションがセットされている場合に有効)
%h
ドメイン名なしのローカルホスト名に展開
%p
パスワードを要求されているユーザ名に展開 (sudoers(5) の rootpw, targetpw, runaspw フラグを尊重する)
%U
変身対象になるユーザ ( -u オプションが同時に指定されていないときは、root がデフォルト) のログイン名に展開される
%u
sudo を起動するユーザのログイン名に展開される
%%
連続する二つの '%' 文字は、1 個の '%' 文字そのものを意味する。
自家特製のプロンプトが、 PAM をサポートしているシステムでシステムのパスワードプロンプトに置き替わるのは、 sudoers で passprompt_override フラグが無効になっていない場合である (訳注: sudoers(5) の passprompt_override の項も参照していただきたい)。
-r role, --role=role
指定された role を含む SELinux のセキュリティ・コンテキストでコマンドを実行する。
-S, --stdin
プロンプトを標準エラーに表示するが、パスワードの読み込みは、 ターミナルデバイスを使わずに、標準入力から行う。パスワードは、 末尾に改行を付けなければならない。
-s, --shell
環境変数 SHELL が設定されていれば、そのシェルを、 設定されていなければ、パスワード・データベースで sudo を起動するユーザのシェルとして指定されているシェルを実行する。 コマンドが指定されている場合は、それをシェルに渡し、シェルの -c オプションを使って実行する。コマンドが指定されていない場合は、 対話的シェルを開く。
-t type, --type=type
指定された type を含む SELinux のセキュリティ・コンテキストでコマンドを実行する。 type が指定されていない場合は、ロールからデフォルトのタイプを推測する。
-U user, --other-user=user
sudo を実行しているユーザではなく、 user というユーザの権限の一覧を表示するために、 -l オプションと組み合わせて使用する。自分以外のユーザの権限の表示は、 セキュリティポリシーによって禁止されているかもしれない。 sudoers ポリシーでこのオプションの使用が認められているのは、 root ユーザを別にすれば、現在使用中のホストで許可するコマンドに ALL が指定してあるユーザだけである。
-u user, --user=user
コマンドをデフォルトの変身対象ユーザ (通常は root) 以外のユーザとして実行する。 user に指定するのは、ユーザ名でもよく、 '#' 記号を頭に付けたユーザ ID 番号 (UID) でもよい (たとえば、UID が 0 なら、#0 と指定する)。多くのシェルでは、 UID の資格でコマンドを実行するには、 '#' をバックスラッシュ ('\') でエスケープしなければならない。 セキュリティポリシーによっては、使用できる UID をパスワード・データベースに登録されているものに限定していることもある。 sudoers ポリシーでは、targetpw オプションが設定されていないかぎり、 パスワード・データベースに存在しない UID も認めている。 他のセキュリティポリシーでは、それは許されないかもしれない。
-V, --version
sudo のバージョン文字列を、セキュリティポリシー・プラグインや 入出力プラグインのバージョン文字列とともに表示する。 sudo を実行するユーザがあらかじめ root になっている場合は、 sudo がビルドされたときに configure スクリプトに渡された引き数が表示される。 プラグインについては、 デフォルト・オプションのようなより詳細な情報が表示されるかもしれない。
-v, --validate
ユーザの保存された認証情報を更新する。このとき、必要ならば、 ユーザの認証を行う。 sudoers プラグインでは、このオプションによって sudo のタイムアウト時間がもう 5 分間 (これがデフォルトのタイムアウト時間) 伸びるが、このオプションがコマンドを実行することはない。 すべてのセキュリティポリシーが認証情報の一時保存に対応しているわけではない。
--
-- オプションがあると、 sudo はそこでコマンドライン引き数の処理をやめる。
さらに、コマンドのために設定したい環境変数も、 VAR=value、たとえば LD_LIBRARY_PATH= /usr/local/pkg/lib といった形でコマンドラインで渡すことができる。コマンドラインで渡す環境変数は、 セキュリティポリシー・プラグインによって課される制限の対象になる。 sudoers ポリシーの場合、コマンドラインで渡される環境変数は、 通常の環境変数と同じ制限の対象になるが、一つだけ重要な相違がある。 sudoers で setenv オプションが設定されているか、実行するコマンドに SETENV タグが付いているか、あるいは、マッチするコマンドが ALL である場合は、 ユーザは他の状況なら禁じられているような環境変数を設定することができるのだ。 詳細については、sudoers(5) のマニュアルを参照していただきたい。

コマンドの実行

sudo がコマンドを実行するとき、 セキュリティポリシーによってコマンドの実行環境が設定される。たいていの場合、 実ユーザ、実効ユーザ、実グループ、実効グループ、及びその ID 番号が、変身対象ユーザの、 パスワード・データベースに記載されているものと同一になるようにセットされる。 所属グループのリストも、( -P オプションが指定されていないかぎり) グループ・データベースに基づいて、初期化される。
セキュリティポリシーは、以下のパラメータを設定することができる。
•
実ユーザ ID と実効ユーザ ID
•
実グループ ID と実効グループ ID
•
補助グループ ID
•
環境のリスト
•
カレント・ワーキング・ディレクトリ
•
ファイル作成時のモード・マスク (umask)
•
SELinux の role と type
•
Solaris の project
•
Solaris の privilege
•
BSD のログインクラス (login class)
•
スケジューリング優先度 (nice value とも言う)

プロセス・モデル

sudo は、コマンドを実行するとき、まず fork(2) を呼び、 実行環境を上記のように設定してから、子プロセスで execve システムコールを呼び出す。 メインの sudo プロセスは、コマンドが完了するまで wait し、完了したら、 コマンドの終了ステータスをセキュリティポリシーの close 関数に渡してから、 終了する。入出力ロギング・プラグインが設定されている場合や、 セキュリティポリシーが明示的にそれを要求している場合は、 擬似端末 ("pty") が新規に作成され、二つ目の sudo プロセスが、 既に存在しているユーザの pty と、コマンドがそこで実行されている新しい pty との間で、 ジョブ制御シグナルを中継するために使用される。 この二つ目の sudo プロセスによって、たとえば、 コマンドのサスペンドやレジュームといったことが可能になるのである。 この仕組みがなければ、コマンドは、POSIX で "orphaned process group" と言われる状態に陥り、どんなジョブ制御シグナルも受け取れないことになってしまうだろう。 なお、特殊ケースとして次のことがある。ポリシー・プラグインが close 関数を定義していず、しかも、pty が要求されていない場合は、 sudo は fork(2) を最初に呼ぶことをせず、直接コマンドを実行する。 sudoers ポリシー・プラグインで close 関数が定義されることになるのは、 入出力ロギングが有効か、pty が要求されているか、 pam_session または pam_setcred が有効な場合だけである。PAM を使用しているシステムでは、 デフォルトで pam_session と pam_setcred が有効になることに注意していただきたい。 (訳注: 上記の「特殊ケースとして」以下についてだが、最近の sudo では、 sudoers ポリシーにおける pam_session や pam_setcred の有効/無効に関係なく、pty が要求されていない場合は、 fork せずに直接コマンドを実行するようである。)

シグナルの処理

コマンドが sudo プロセスの子プロセスとして実行されているとき、 sudo は自分が受け取ったシグナルをそのコマンドに中継する。 ただし、SIGINT や SIGQUIT シグナルが中継されるのは、 そのコマンドが新たに開いた pty で実行されているときか、 シグナルがカーネルではなく、ユーザ・プロセスによって送出されたときだけである。 そうなっていることで、ユーザが control-C を入力するたびに、 コマンドが SIGINT シグナルを二重に受け取らないようにしているのだ。 SIGSTOP や SIGKILL のようないくつかのシグナルは、 捕獲できないので、コマンドに中継されることもない。 だから、 sudo によって実行されているコマンドをサスペンドしたかったら、 原則として、SIGSTOP ではなく、SIGTSTP コマンドを使用するべきである。
sudo は原則として、自分が受け取ったシグナルを子プロセスに中継するわけだが、 自分が実行しているコマンドから来たシグナルは、中継しないという例外がある。 コマンドが意図に反して自分自身を殺してしまわないようにしているのだ。 システムによっては、reboot(8) コマンドが、システムをリブートする前に、 自分自身を除くすべてのノン・システム・プロセスに SIGTERM を送るものがある。 そうした場合も、中継の抑制があるため、 sudo は自分が受け取った SIGTERM シグナルを reboot(8) に送り返さない。もし送り返すようになっていたら、 システムが実際にリブートする前に reboot(8) が終了して、 システムがシングルユーザ・モードによく似た半分死んだ状態 (half-dead state) に陥ってしまうだろう。とは言え、注意していただきたいが、 この中継の抑制が行われるのは、 sudo によって直接実行されるコマンドに対してのみであり、 そのコマンドが生成するかもしれない他のどんなプロセスに対しても当てはまらない。 それ故、reboot(8) や shutdown(8) を呼び出すスクリプトを sudo 経由で実行すると、システムがそうしたわけのわからない状態に陥ることがある。 reboot(8) や shutdown(8) の実行に exec() ファミリーの関数ではなく、 system() 関数を使用していると、 ( system() は、呼び出しプロセスとコマンドの間にシェルを挟むため) そうしたことが起こりかねないのだ。
入出力ロギング・プラグインがロードされていない場合に、 ポリシー・プラグインが close() 関数を定義してもいず、 コマンドのタイムアウトを設定していることもなく、コマンドを新たに開いた pty で実行することを要求してもいなかったならば、 sudo は、 コマンドを子プロセスとしてではなく、直接実行するかもしれない。

プラグイン

プラグインは、sudo.conf(5) ファイルの Plugin 命令 (directive) で指定することができる。プラグインは、(システムがサポートしていれば) 動的な共有オブジェクト (dynamic shared object) としてロードすることもできるし、 また、 sudo のバイナリに直接組み込むこともできる。sudo.conf(5) ファイルが存在しない場合や、sudo.conf(5) ファイルに Plugin の行がない場合は、 sudo は従来どおり、 sudoers のセキュリティポリシーと入出力ロギングを使用することになる。 /etc/sudo.conf ファイルの詳細については、 sudo.conf(5) のマニュアルを参照していただきたい。 sudo プラグインの設計についての詳しい情報は、 sudo_plugin(5) のマニュアルにある。

終了ステータス

コマンドの実行に成功した場合、 sudo が返す終了ステータスは、 実行したプログラムの終了ステータスである。 コマンドがシグナルを受け取ることによって終了した場合は、 sudo はコマンドを終了させたシグナルを自分自身に送るようになっている。
それ以外の場合、設定やパーミッションに問題があったり、 sudo が指定されたコマンドを実行できなかったりしたときは、 sudo は終了ステータス 1 で終了する。後者の場合は、 エラーメッセージが標準エラーに表示される。 sudo がユーザの PATH にある一つ以上のエントリを stat(2) できなかったときも、 エラーが標準エラーに表示される (ただし、PATH 中のディレクトリが存在しなかったときや、実際にはディレクトリでなかったときは、 そのエントリは無視され、エラーは表示されない)。そういったことは、 通常の状態では起きるはずがないことである。stat(2) が "permission denied" を返す理由で一番よくあるのは、ユーザがオートマウンターを使用していて、 PATH 中のディレクトリの一つが目下到達不可能なマシンにある場合だ。

セキュリティに関するメモ

sudo は、外部のコマンドをできるだけ安全に実行しようとする。
偽コマンドの実行 (command spoofing) を防止するため、 sudo はコマンドを捜してユーザの PATH を検索する際に、"." や "" (どちらもカレント・ディレクトリを意味する) を最後に調べる (そのどちらか、 あるいは両方が、PATH 中に存在すればだが)。とは言え、環境変数 PATH そのものは変更されずに、 そのまま sudo が実行するプログラムに渡されることに注意していただきたい。
次のようなファイルを実行する sudo 権限を、絶対にユーザに許可してはいけない。 すなわち、そのユーザに書き込みできるファイルや、 そのユーザに書き込みできるディレクトリにあるファイルを実行する権限である。 もし、ユーザがコマンドを書き換えたり、別のコマンドと置き換えたりできるならば、 そのユーザは自分が実行できるコマンドに何でも追加できるわけで、 それを制限する方法はまったくないのだ。
sudo は通常、自分が明示的に実行するコマンドしかログに記録しないことに注意していただきたい。 ユーザが sudo su や sudo sh といったコマンドを実行した場合、 そのシェルからさらに実行されるコマンドは、 sudo のセキュリティポリシーの対象にはならないのだ。 同じことが、シェル・エスケープを提供するコマンド (たいていのエディターが、 それに含まれる) についても言える。確かに、入出力ロギングが有効になっている場合は、 シェルからさらに実行されるコマンドも、その入力や出力を記録されることになるが、 従来からあるログファイルに記録されるわけではないのである。従って、 ユーザに sudo 経由で、あるコマンドを実行する権限を与えるときは、 そのコマンドが事実上ルート・シェルをユーザにうっかり与えていないことを、 念には念を入れて確認しなければならない。もっと詳しいことをお知りになりたかったら、 sudoers(5) のマニュアルの「シェル・エスケープを防止する」というセクションをご覧になるとよい。
セキュリティ上問題になりかねない情報を漏洩しないように、 sudo はデフォルトでは、自己を実行中のコアダンプを抑止している (指定されたコマンドを実行するときに、コアダンプを有効にし直すのだ)。 この動作は昔からのものであり、たいていのオペレーティングシステムが setuid プロセスにデフォルトではコアダンプを許していた時代からそうなっていた。 sudo 自体のクラッシュをデバッグするためにコアダンプを有効に戻したいならば、 以下のように、sudo.conf(5) ファイルで "disable_coredump" を false にすればよい。 
 


Set disable_coredump false

詳細については、sudo.conf(5) のマニュアルを参照していただきたい。

環境変数

sudo は以下の環境変数を利用する。 実行するコマンドの環境が実際にどうなるかは、セキュリティポリシー次第である。
EDITOR
環境変数 SUDO_EDITOR や VISUAL が設定されていないとき、 -e (sudoedit) モードで使用するデフォルトのエディタ。
MAIL
-i オプションが指定された場合や、 sudoers で env_reset が有効になっている場合には ( env_keep のリストに MAIL が存在しないかぎり)、変身対象ユーザのメールスプールにセットされる。
HOME
次の場合には、変身対象ユーザのホームディレクトリにセットされる。 -i や -H オプションが指定された場合、 -s オプションが指定され、かつ sudoers で set_home が設定されている場合、 always_set_home が sudoers で有効になっている場合、 あるいは、 env_reset が sudoers で有効になっていて、 しかも HOME が env_keep のリストに存在しない場合。
LOGNAME
次の場合には、変身対象ユーザのログイン名にセットされる。 -i オプションが指定された場合、 set_logname オプションが sudoers で有効になっている場合、 あるいは、 env_reset オプションが sudoers で有効になっていて、 LOGNAME が env_keep のリストに存在しない場合。
PATH
セキュリティポリシーによって上書きされるかもしれない。
SHELL
-s オプションで起動するシェルを決めるのに使用する。
SUDO_ASKPASS
ターミナルが利用できない場合や、-A オプションが指定された場合に、 パスワードを読み込むのに使用するヘルパー・プログラムのパスを指定する。
SUDO_COMMAND
sudo が実行するコマンドにセットされる。
SUDO_EDITOR
-e (sudoedit) モードで使用するデフォルトのエディタ。
SUDO_GID
sudo を起動したユーザのグループ ID にセットされる。
SUDO_PROMPT
デフォルトのパスワード・プロンプトとして使用する。
SUDO_PS1
設定すると、実行されるプログラムの PS1 がこの変数の値にセットされる。
SUDO_UID
sudo を起動したユーザのユーザ ID にセットされる。
SUDO_USER
sudo を起動したユーザのログイン名にセットされる。
USER
上で述べた LOGNAME と同じ値にセットされる。
USERNAME
USER と同じ。
VISUAL
SUDO_EDITOR が設定されていない場合に、 -e (sudoedit) モードで使用するデフォルトのエディタ。

ファイル

/etc/sudo.conf
sudo フロントエンドの設定ファイル

用例

注意: 以下の例は、セキュリティポリシーが適切に設定されていることを前提にしている。
読み取り不可のディレクトリのファイル一覧を取得する。 
 


$ sudo ls /usr/local/protected

ユーザ yaz のホームディレクトリのファイル一覧を取得する。 ただし、~yaz を含むファイルシステムが、別のマシンにあって、 root でアクセスできるようにエクスポートされていない場合。 
 


$ sudo -u yaz ls ~yaz

ユーザ www として index.html ファイルを編集する。 
 


$ sudo -u www vi ~www/htdocs/index.html

root と adm グループのユーザだけがアクセスできるシステムログを閲覧する。 
 


$ sudo -g adm view /var/log/syslog

jim に変身してエディタを実行する。プライマリグループには別のグループを指定する。 
 


$ sudo -u jim -g audio vi ~jim/sound.txt

マシンをリブートする。 
 


$ sudo shutdown -r +15 "quick reboot"

/home パーティションに存在するディレクトリのディスク使用量リストを作成する。 cd やファイル・リダイレクションがきちんと動作するように、 コマンドをサブシェルで実行している点に注目していただきたい。 
 


$ sudo sh -c "cd /home ; du -s * | sort -rn > USAGE"

参照項目

su(1), stat(2), passwd(5), sudo.conf(5), sudoers(5), sudo_plugin(5), sudoreplay(8), visudo(8)

履歴

sudo の簡単な履歴については、 sudo の配布に含まれている HISTORY ファイルをご覧いただきたい。 (https://www.sudo.ws/history.html)

作者

多数の人々が長年に渡って sudo の開発に携わってきた。 当バージョンは主として次の者が書いたコードからできている。
 
Todd C. Miller
sudo の開発に貢献してくださった方々の詳細なリストについては、 配布物中の CONTRIBUTORS ファイルをご覧になっていただきたい。 (https://www.sudo.ws/contributors.html)

警告

もし、ユーザが sudo 経由で任意のコマンドを実行することを許可されているなら、 そのユーザがルート・シェルを手に入れるのを防止する簡単な方法は存在しない。 また、(エディタをはじめとする) 多くのプログラムが、 シェル・エスケープを通してユーザがコマンドを実行できるようにしており、 この方法でユーザは sudo によるチェックをすり抜けることができる。 とは言え、たいていのシステムでは、sudoers(5) プラグインの noexec 機能を使用することでシェル・エスケープを抑止することが可能だ。
下記のように sudo 中で直に cd コマンドを実行しても意味がない。 
 


$ sudo cd /usr/local/protected

なぜなら、このコマンドが終了したとき、その親プロセス (すなわち、 sudo を実行したシェル) は、 sudo を実行する前と同じ状態に戻るからだ。 cd については、「用例」セクションもご覧になっていただきたい。
sudo を介してシェルスクリプトを実行すると、ある種のオペレーティング・システムで setuid シェルスクリプトを危険なものにしているのと同一の、 カーネルのバグが表面化するおそれがある (使用している OS に /dev/fd/ ディレクトリがあれば、setuid シェルスクリプトはたいてい安全である)。

バグ

sudo にバグを発見したと思ったら、https://bugzilla.sudo.ws/ にアクセスして、バグレポートを提出していただきたい。

サポート

ある程度の無料サポートが sudo-users メーリングリストを通して利用できる。 購読やアーカイブの検索には、次の URL を御覧になるとよい。 https://www.sudo.ws/mailman/listinfo/sudo-users

免責

sudo は「現状のまま」提供される。 明示的な、あるいは黙示的ないかなる保証も、 商品性や特定目的への適合性についての黙示的な保証を含め、 またそれのみに止まらず、これを否認する。詳細な全文については、 sudo と一緒に配布されている LICENSE ファイルや、 次の Web ページをご覧いただきたい。 https://www.sudo.ws/license.html