名前¶

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

書式¶

sudo -h | -K | -k | -V

sudo -v [-AknS] [-g group name|#gid] [-p prompt] [-u user name|#uid]

sudo -l[l] [-AknS] [-g group name|#gid] [-p prompt] [-U user name] [-u user name|#uid] [command]

sudo [-AbEHnPS] [-C fd] [-g group name|#gid] [-p prompt] [-u user name|#uid] [VAR=value] [-i | -s] [command]

sudoedit [-AnS] [-C fd] [-g group name|#gid] [-p prompt] [-u user name|#uid] file ...

説明¶

sudo を使用すると、許可されたユーザーが、 スーパーユーザや他のユーザに変身して、コマンドを実行することが可能になる。 許可の範囲については、セキュリティ・ポリシーの指定するところに従う。 実 uid と gid、実効 uid と gid は、変身の対象になるユーザの、 パスワード・データベースに記載されているものと同一になるようにセットされる。 所属するグループについても (-P オプションが指定されていないかぎり)、 グループ・データベースに基づいて初期化される。

sudo はセキュリティ・ポリシーと入出力のロギングについて、 プラグイン方式をサポートしている。このため、sudo フロントエンドとシームレスに共動するポリシー・モジュールや I/O ロギング・モジュールを、サードパーティが独自に開発して配布することが可能である。 デフォルトのセキュリティ・ポリシーは sudoers であり、その設定は、 /etc/sudoers ファイル、もしくは LDAP を通して行われる。 詳細については、「プラグイン」セクションを参照してほしい。

セキュリティ・ポリシーによって、あるユーザに sudo を使用する権限があるかどうか、 あるとすれば、どんな権限を持っているかが決定される。 セキュリティ・ポリシーは、ユーザにパスワードや他の認証方法を使って、 本人であることを証明するように要求してもよい。認証が必要な場合、 ユーザがパスワードを (設定によって変更可能な) 制限時間内に入力しないと、 sudo は時間切れで終了する。この制限時間はポリシー次第であり、 sudoers セキュリティ・ポリシーの場合、 パスワード・プロンプトがタイムアウトするまでのデフォルトの時間は、 5 分間である.

セキュリティ・ポリシーは、一定時間内ならユーザが認証なしで sudo を何度も実行できるように、認証情報の一時保存 (credential caching) をサポートしてもよい。sudoers ポリシーでは、sudoers(5) で変更されないかぎり、認証情報を 5 分間保持する。 ユーザは sudo に -v を付けて実行することで、 command を実行しないでも、保存された認証情報を更新することができる。

sudoedit というコマンド名で起動するのは、sudo に -e オプション (下記参照) を付けて実行するのと同じである。

セキュリティ・ポリシーは、ユーザが sudo を使おうとして 成功した場合も失敗した場合も、それをログに記録することができる。 I/O プラグインが設定によって組み込まれている場合は、 実行しているコマンドの入出力もログに残すことができる。

オプション¶

sudo では以下のコマンドライン・オプションが使用できる。

-A

通常 sudo がパスワードを要求するとき、 パスワードはユーザが使用している端末から読み込まれる。 -A (askpass) オプションを指定すると、 ヘルパー・プログラム (グラフィカルなものでもよい) が実行され、ユーザのパスワードを読み込んで、それを標準出力に書き出す。 環境変数 SUDO_ASKPASS が設定されているときは、 それがヘルパー・プログラムのパスになる。それ以外の場合は、 /etc/sudo.conf に askpass プログラムを指定している行が存在すれば、 その値が使用される。一例を挙げよう。

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

利用できる askpass プログラムがないと、sudo はエラーメッセージを出して、終了する。

-b

-b (background) オプションを付けると、sudo は指定されたコマンドをバックグラウンドで実行する。 -b オプションを使用すると、 シェルのジョブ制御を使ってプロセスを操作できなくなるので、注意してほしい。 バックグラウンドモードでは、対話的なコマンドのほとんどがまともに動かないだろう。

-C fd

通常、sudo は、(コマンドを実行する前に) 標準入力、標準出力、 標準エラーを除いて、 開いているファイル・ディスクリプタをすべて閉じることになっている。 -C (close from) オプションを使えば、 標準エラーより番号が大きい (すなわち、ファイル・ディスクリプタ 3 以上の) どのファイル・ディスクリプタから閉じていくかを、ユーザが指定することができる。 3 未満の値は指定できない。セキュリティ・ポリシーによっては、ユーザが -C オプションを使用するのを制限していることがある。 sudoers ポリシーが -C オプションの使用を許可するのは、 管理者が closefrom_override オプションを有効にしているときのみである。

-E

-E (preserve environment) オプションを指定すると、 現在の環境変数をそのまま保持するのがユーザの意向だと、 セキュリティ・ポリシーに伝えることになる。 -E を指定しても、ユーザが環境を保持する許可を持っていない場合は、 セキュリティ・ポリシーがたぶんエラーを返すだろう。

-e

-e (edit) オプションを指定するのは、 ユーザがコマンドの実行ではなく、 一個以上のファイルを編集しようとしていることを意味する。 セキュリティ・ポリシーの参照では、 コマンド名として文字列 "sudoedit" が使用される。 セキュリティ・ポリシーによってユーザに権限があることが認められると、 次のようなことが順番に行われる。

-g group

通常 sudo はコマンドを実行するとき、プライマリ・グループを、 パスワード・データベースで変身対象ユーザ (デフォルトでは root である) のプライマリ・グループとして指定されているグループに設定する。これに対して、 -g (group) オプションを使用すると、 sudo はプライマリ・グループを group に設定して、 コマンドを実行することになる。グループ名の代わりに gid を指定するときは、 #gid という書き方をする。gid としてコマンドを実行する場合、 多くのシェルでは '#' をバックスラッシュ ('\') でエスケープしなければならない。 なお、-u オプションが同時に指定されていない場合、コマンドは (root としてではなく) sudo を起動したユーザの資格で実行される。 いづれにしろ、プライマリ・グループが group に設定されることに変わりはない。 (訳注: -g オプションを使用するには、 sudoers ポリシーの場合なら、sudoers ファイルのユーザ設定で、 変身対象となるグループを設定しておく必要がある。詳細については、 sudoers(5) のマニュアルの該当個所を参照してほしい。)

-H

-H (HOME) オプションを指定すると、 セキュリティ・ポリシーは、環境変数 HOME を、パスワード・データベースで変身対象ユーザ (デフォルトでは root) のホームディレクトリとして指定されているディレクトリに設定することになる。 ポリシーによっては、それがデフォルトの動作になっていることもある。

-h

-h (help) オプションを指定すると、 sudo は簡単なヘルプメッセージを標準出力に表示して、終了する。

-i [command]

-i (simulate initial login) オプションを指定すると、 パスワード・データベースの変身対象ユーザのエントリで指定されてているシェルが、 ログイン・シェルとして実行される。すなわち、.profile や .login といった、ログイン用のリソースファイルが、 シェルによって読み込まれるわけだ。コマンドを指定すると、 それがシェルに渡され、シェルの -c オプションを使って実行される。 コマンドを指定しない場合は、対話的シェルが起動されることになる。sudo は、 シェルを実行する前に、変身対象ユーザのホームディレクトリに移動しようとする。 セキュリティ・ポリシーは、環境変数が最小限になるように、すなわち、 ユーザが普通にログインしたときの環境と同様になるように、 環境を初期化すべきである。 sudoers ポリシーを使用している場合に、 -i オプションがコマンドの実行環境にどんな影響を与えるかについては、 sudoers(5) のマニュアルの「コマンド環境」セクションに説明がある。

-K

-K (sure kill) オプションは -k オプションに似ているが、 ユーザの保存された認証情報を完全に消去してしまう点と、 コマンドや他のオプションと組み合わせて使用できない点で異なっている。 このオプションはパスワードを要求しない。 すべてのセキュリティ・ポリシーが 認証情報の一時保存をサポートしているわけではない。

-k [command]

-k (kill) オプションを単独で使うと、 sudo はユーザの保存された認証情報を無効にする。 次回 sudo を実行するとき、パスワードが要求されることになるわけだ。 このオプション自体はパスワードを必要としない。 なお、このオプションが追加されたのは、ユーザが .logout ファイルで、sudo をパスワードなしで実行できる期間を終了させることができるようにするためである。 すべてのセキュリティ・ポリシーが認証情報の一時保存をサポートしているわけではない。

-k オプションをコマンドや、 パスワードを必要とするような他のオプションと組み合わせて使用すると、 sudo はユーザの保存された認証情報を無視することになる。 その結果、sudo は (セキュリティ・ポリシーでパスワードを要求するようになっているならば) プロンプトを出してパスワードを要求する。このとき、 ユーザの保存された認証情報の更新は行わない。

-l[l] [command]

command を指定しない場合、-l (list) オプションは、 sudo を実行しているユーザ (あるいは、-U で指定したユーザ) が、 現在ログインしているホストで許可されている (及び、禁じられている) コマンドを列挙する。command を指定した場合は、 セキュリティ・ポリシーで許可されているコマンドならば、その絶対パスを表示する。 指定する command に引数を付けると、それも一緒に表示される (訳注: セキュリティ・ポリシーで、許可するコマンドに引数まで指定している場合は、 それにマッチする引数を -l に続く command にも必ず付けなければならない)。 指定したコマンドが許可されていない場合は、 sudo がステータス 1 で終了する。-l オプションに l という引数を付けた場合や (すなわち -ll)、 -l を複数回指定した場合は、長い方のリスト形式が使用される。

-n

-n (non-interactive) オプションがあると、 sudo は ユーザにパスワードを要求するプロンプトを出さない。 実行するコマンドにパスワードが必要な場合、 sudo はエラーメッセージを表示して、終了する。

-P

-P (preserve group vector) オプションを指定すると、 sudo は、sudo を実行するユーザが所属するグループのリストを、 変更せずにそのまま使用する。sudoers ポリシーの場合、デフォルトでは、 所属グループの初期値として、 変身対象となるユーザが所属するグループのリストを設定するのである。とは言え、 実 gid や 実効 gid が変身対象ユーザと同一になるようにセットされる点には、 変わりがない。

-p prompt

-p (prompt) オプションを使うと、 デフォルトのパスワードプロンプトを変更して、好きな文句にすることができる。 sudoers ポリシーでは以下のパーセント (`%') エスケープが使用できる。

-S

-S (stdin) オプションを指定すると、 sudo はパスワードをターミナルデバイスからではなく、 標準入力から読み込む。パスワードは末尾に改行を付けなければならない。

-s [command]

-s (shell) は、環境変数 SHELL が設定されていれば、 そのシェルを、さもなければ、 パスワード・データベースで指定されているシェルを実行する。 コマンドが指定されている場合には、それをシェルに渡し、シェルの -c オプションを通じて実行させる。 コマンドが指定されていなければ、対話的シェルを開く。

-U user

-U (other user) オプションは、-l と組み合わせて使用し、 誰の権限の一覧を表示するかを指定する。自分以外のユーザの権限の表示は、 セキュリティ・ポリシーによって禁止されているかもしれない。 sudoers ポリシーでこのオプションの使用が認められているのは、 root ユーザを別にすると、現在使用中のホストで許可するコマンドに ALL が指定してあるユーザだけである。

-u user

-u (user) オプションを指定すると、sudo は指定されたコマンドを root 以外のユーザとして実行する。 ユーザ名の代わりに uid を指定するときは、#uid という書き方をする。 多くのシェルでは、uid の資格でコマンドを実行するときは、 '#' をバックスラッシュ ('\') でエスケープしなければならない。 セキュリティ・ポリシーによっては、使用できる uid をパスワード・データベースに記載されているものに限定していることもある。 sudoers ポリシーでは、 targetpw オプションが設定されていないかぎり、 パスワード・データベースに存在しない uid も認めている。 他のセキュリティ・ポリシーでは、これは許されないかもしれない。

-V

-V (version) オプションを指定すると、 sudo はそのバージョン文字列を、セキュリティ・ポリシー・プラグインや I/O プラグインのバージョン文字列とともに表示する。 sudo -V を実行するユーザがあらかじめ root になっている場合は、 sudo がビルドされたときに configure スクリプトに渡された引数が表示される。また、プラグインについても、 デフォルト・オプションのようなより詳細な情報が表示されるかもしれない。

-v

-v (validate) オプションを指定すると、sudo は ユーザの保存された認証情報を更新する。このとき、必要ならば、 パスワードによる認証を行う。sudoers プラグインでは、 このオプションによって sudo のタイムアウト時間がもう 5 分間 (あるいは、何分であれ、sudoers で設定されたタイムアウト時間) 伸びるが、 このオプションがコマンドを実行することはない。 すべてのセキュリティ・ポリシーが認証情報の一時保存に対応しているわけではない。

--

-- オプションがあると、 sudo はそこでコマンドライン引き数の処理をやめる。

[訳注]:

このほか、sudo-1.8.4 では使用できなくなくなったが、sudo-1.8.3 には -D というオプションも存在した。ご参考のため挙げておくと、 次のようなものである。

さらに、コマンドのためにセットしたい環境変数も、VAR=value、 たとえば LD_LIBRARY_PATH=/usr/local/pkg/lib といった形でコマンドラインから渡すことができる。 コマンドラインから渡される変数は、通常の環境変数と同じ制限の対象になるが、 一つだけ重要な違いがある。sudoers で setenv オプションが設定されているか、実行されるコマンドに SETENV タグがついているか、 あるいは、マッチするコマンドが ALL である場合は、 ユーザがほかの状況でなら禁じられているような変数をセットすることができるのだ。 詳細については sudoers(5) を参照してほしい。

プラグイン¶

プラグインは /etc/sudo.conf の内容に基づいて、動的にロードされる。 /etc/sudo.conf が存在しない場合や、存在しても Plugin の行がない場合は、 sudo はこれまでどおり、 sudoers のセキュリティ・ポリシーと I/O ロギングを使用する。 それは、次のように /etc/sudo.conf ファイルに記述するのと同じことである。

 #
 # Default /etc/sudo.conf file
 #
 # 書式:
 #   Plugin plugin_name plugin_path
 #   Path askpass /path/to/askpass
 #   Path noexec /path/to/noexec.so
 #   Debug sudo /var/log/sudo_debug all@warn
 #   Set disable_coredump true
 #
 # The plugin_path が絶対パスでない場合は、 /usr/local/libexec からの
 # 相対パスである。、
 # plugin_name は、プラグイン中の、プラグインのインターフェース構造を
 # 含むグローバルシンボルと同じものである。
 #
 Plugin sudoers_policy sudoers.so
 Plugin sudoers_io sudoers.so

Plugin 行は、キーワード Plugin に始まり、 symbol_name と path が続く。 path は、プラグインを含む共有オブジェクト・ファイルへのパスである。 symbol_name はプラグイン共有オブジェクト中の policy_plugin 構造体や io_plugin 構造体の名前である。 path は絶対パスでも相対パスでもよい。 相対パスの場合は、 /usr/local/libexec ディレクトリを基点にした相対パスである。 path の後ろに他のパラメータを付けても、無視される。 Plugin や Path で始まらない行は、 ただ単に無視される。

[訳注]:

sudo-1.8.3 までは、上記の説明どおり、キーワードに Plugin と Path しか使用できなかった。

sudo-1.8.4 以上では、上記の書式にもあるように、Debug や Set で始まる行も有効である。「デバッグ・フラグ」や 「セキュリティに関する注意点」セクションも参照していただきたい。

また、sudo-1.8.5 以上では、path の後ろにパラメータを続けて書くことで (複数個あるときは空白で区切る)、 それをオプションとしてプラグインに渡すことが可能になっている。 たとえば、以下のようにだ。

Plugin sudoers_policy sudoers.so sudoers_file=/etc/sudoers sudoers_uid=0 sudoers_gid=0 sudoers_mode=0440

詳細については、sudo_plugin(8) のマニュアルをご覧になること。

パス¶

Path 行は、キーワード Path に始まり、 設定するパスの名前とその値が続く。一例を挙げる。

 Path noexec /usr/local/libexec/sudo_noexec.so
 Path askpass /usr/X11R6/bin/ssh-askpass

次のようなプラグインではないプログラムやライブラリのパスを /etc/sudo.conf ファイルで設定することができる。

askpass

端末が利用できないときに、 ユーザのパスワードを読み込むのに使用するヘルパー・プログラムの絶対パス。 たとえば、 sudo がグラフィカルな (つまり、テキストベースではない) アプリケーションから実行される場合がこれに当たる。 askpass で指定されたプログラムは、 自分に渡された引数をプロンプトとして表示し、 ユーザのパスワードを標準出力に書き出すべきである。 askpass の値は、環境変数 SUDO_ASKPASS によって上書きすることができる。

noexec

ライブラリ関数 execv(), execve(), fexecve() のダミー版 (単にエラーを返すだけの関数) が入っている共有ライブラリの絶対パス。 これは LD_PRELOAD やそれに相当するものをサポートしているシステムで noexec 機能を実現するために使用される。 デフォルトでは /usr/local/libexec/sudo_noexec.so になっている。

デバッグ・フラグ (sudo-1.8.4 の新機能)¶

バージョン 1.8.4 以上の sudo は、 デバッグのための柔軟な枠組みに対応しており、 問題が発生したとき、sudo の内部で何が起きているかを突き止めるために、 それを利用することができる。

Debug 行の構成は、Debug というキーワードに始まり、それに、デバッグ対象のプログラム名 (sudo, visudo, sudoreplay) とデバッグファイル名が続き、 最後にコンマで区切ったデバッグ・フラグのリストが来るという形になっている (訳注: Debug 行も /etc/sudo.conf に記載する)。 デバッグフラグのシンタクスは、sudo と sudoers プラグインでは、 subsystem@priority という書式を用いるが、 「,」というコマンドを含まないかぎり、 プラグインが別の書式を使っても構わない。

一例を挙げよう。

 Debug sudo /var/log/sudo_debug all@warn,plugin@info

上記のように指定すれば、warn レベル以上のすべてのデバッグメッセージを ログに記録することになる。さらに、plugin サブシステムに関しては、 info レベルのメッセージも記録する。

現在のところ、一プログラムあたり一行の Debug エントリしか使用できない。 プログラム名が sudo の Debug 行は、 sudo フロントエンド、sudoedit、及び sudo のプラグインによって共有される。将来のリリースでは、プラグインごとの Debug 行をサポートするかもしれない。 また、一つのプログラムに対する複数のデバッグファイルをサポートするかもしれない。

sudo フロントエンドが使用する priority (重大度) を 深刻なものから挙げると、crit, err, warn, notice, diag, info, trace, debug である。 ある priority を指定すると、 それよりも深刻なすべての priority も同時に指定したことになる。 たとえば、notice という priority を指定すれば、 notice レベル以上のデバッグメッセージがログに記録されるわけである。

sudo では以下のサブシステムが使用できる。

all

あらゆるサブシステムにマッチする

args

コマンドライン引数の処理

conv

ユーザとのやりとり

edit

sudoedit

exec

コマンドの実行

main

sudo のメイン関数

netif

ネットワーク・インターフェースの取扱い

pcomm

プラグインとのやりとり

plugin

プラグインの設定

pty

擬似 tty に関連したコード

selinux

SELinux に特有の取扱い

util

ユーティリティ関数群

utmp

utmp の取扱い

返り値¶

プログラムの実行に成功した場合、sudo が返す終了ステータスは、 実行したプログラムの終了ステータスそのものである。

そうでない場合、設定やパーミッションに問題があったり、 sudo が指定されたコマンドを実行できなかったりしたときは、 sudo は返り値 1 で終了する。 後者の場合は、エラーメッセージが標準エラーに表示される。 また、sudo がユーザの PATH にある一つ以上のエントリを stat(2) できなかったときも、 エラーが標準エラーに出力される (ただし、そのディレクトリが存在しなかったり、 実際にはディレクトリでなかったりした場合は、 そのエントリは無視され、エラーは表示されない)。そうしたことは、 正常な環境では起きないはずのことである。stat(2) が "permission denied" を返す理由で一番よくあるのは、 ユーザーがオートマウントを使用していて、PATH にあるディレクトリの一つが目下到達不可能なマシンにある場合だ。

セキュリティに関する注意点¶

sudo は外部のコマンドをできるだけ安全に実行しようとする。

偽コマンドの実行 (command spoofing) を防止するため、 sudo はコマンドを捜してユーザの PATH を検索する際に、 "." と "" (どちらもカレントディレクトリを意味する) を最後に調べる (そのどちらか、あるいは両方が PATH 中に存在すればだが)。 とは言え、環境変数 PATH そのものは変更されずに、 そのまま sudo が実行するプログラムに渡されることに注意してほしい。

sudo は通常、 自分が明示的に実行したコマンドしかログに記録しないことに気を付けてほしい。 ユーザが sudo su や sudo sh といったコマンドを実行した場合、そのシェルから続いて実行されるコマンドは sudo のセキュリティ・ポリシーの対象にならない。 シェル・エスケープを提供するコマンドについても (たいていのエディタが それに含まれる) 同じことが言える。 確かに、I/O ロギングが有効になっている場合は、 シェルから続いて実行されるコマンドも、その入力や出力を記録されることになるが、 従来からあるログに記録されるわけではないのである。 こうしたことから、ユーザに sudo 経由でコマンドの使用を許すときは、 そのコマンドが事実上ルート・シェルをうっかりユーザに与えていないかを、 念には念を入れて確認しなければならない。もっと詳しいことが知りたかったら、 sudoers(5) の「シェル・エスケープを防止する」 のセクションを御覧になるとよい。

セキュリティ上問題になりかねない情報を漏洩しないように、 sudo はデフォルトでは、自己を実行中のコアダンプを抑止している (指定されたコマンドを実行するときには、コアダンプを有効にし直すのである)。 sudo そのもののクラッシュをデバッグするために、 コアダンプを有効に戻したいならば、 /etc/sudo.conf ファイルで "disable_coredump" を false にすればよい。(訳注: キーワード Set は sudo-1.8.4 以上でなければ、 使用できない。)

 Set disable_coredump false

注意してほしいのは、たいていのオペレーティングシステムが、 デフォルトでは setuid プログラムのコアダンプを抑止していることだ。 sudo もそうしたプログラムの一つである。 そこで、実際に sudo のコアダンプ・ファイルを取得するには、 setuid プロセスに対するコアダンプを有効にする必要があるかもしれない。 BSD や Linux のシステムでは、これは sysctl コマンドによって行われる。 Solaris では coreadm コマンドが使用できる。

環境変数¶

sudo は以下の環境変数を利用する。実行するコマンドの環境の内容は、 セキュリティ・ポリシーによる制御の対象になる。

EDITOR

環境変数 SUDO_EDITOR や VISUAL が設定されていないとき、 -e (sudoedit) モードで使用するデフォルトのエディタ

MAIL

-i オプションが指定された場合や、 sudoers で env_reset が有効になっている場合に、 変身対象ユーザのメールスプールにセットされる

HOME

-i や -H オプションが指定された場合や、 sudoers で env_reset や always_set_home が設定されている場合、あるいは sudoers で set_home が設定され、 かつ -s オプションが指定された場合に、 変身対象ユーザのホームディレクトリにセットされる

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

変身対象ユーザにセットされる (オプション -u が指定されていなければ、 root になる)

VISUAL

変数 SUDO_EDITOR が設定されていない場合に、 -e (sudoedit) モードで使用するデフォルトのエディタ

ファイル¶

/etc/sudo.conf

sudo フロントエンドの設定ファイル

[訳注]:

念のため、次の二つを追加しておく。詳細については sudoers(5) をご覧いただきたい。

用例¶

注意: 以下の例は、 セキュリティ・ポリシーが適切に設定されていることを前提にしている。

読み取り不可のディレクトリのファイル一覧を取得する。

 $ 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"

関連項目¶

grep(1), su(1), stat(2), passwd(5), sudoers(5), sudo_plugin(8), sudoreplay(8), visudo(8)

作者¶

多数の人々が長年に渡って sudo の開発に取り組んできた。当バージョ ンは主として次の者が書いたコードからできている。

        Todd C. Miller

sudo の開発に貢献してくださった方々のリストについては、 sudo の配布に含まれる CONTRIBUTORS ファイルをご覧いただきたい (http://www.sudo.ws/sudo/contributors.html)。

履歴¶

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

警告¶

ユーザが sudo 経由で任意のコマンドを実行することを許可されているならば、 そのユーザがルート・シェルを獲得するのを防止する簡単な方法はない。 また、(エディタを含む) 多くのプログラムが、 シェル・エスケープを通してユーザがコマンドを実行できるようにしており、 この方法でユーザは sudo のチェックを回避することができる。 とは言え、たいていのシステムでは、 sudoers(5) モジュールの noexec 機能を用いて、 シェル・エスケープを抑止することが可能である。

下記のように sudo の中で直に cd コマンドを実行しても意味がない。

 $ sudo cd /usr/local/protected

なぜなら、このコマンドが終了したとき、その親プロセス (つまり、 sudo を実行したシェル) は相変わらず元の状態のままだからだ。 より詳しく知りたかったら、「用例」セクションを御覧になってほしい。

sudo を介してシェルスクリプトを実行すると、 ある種のオペレーティングシステムで setuid シェルスクリプトを危険なものにしているのと同一の、 カーネルのバグが表面化するおそれがある (使用している OS に /dev/fd/ ディレクトリがあれば、setuid シェルスクリプトはたいてい安全である)。

バグ¶

sudo にバクを発見したと思ったら、下記のページにアクセスして、 バグレポートを提出していただきたい。
http://www.sudo.ws/sudo/bugs/

サポート¶

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

免責¶

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