Provided by: manpages-ja_0.5.0.0.20180315+dfsg-1_all 
名前
sudo.conf - sudo フロントエンドの設定
説明
sudo.conf ファイルは、sudo フロントエンドの設定に使用される。 セキュリティポリシー・プラグ
イン、入出力ロギング・プラグイン、 デバッグ・フラグの指定をはじめ、 プラグインが何かにはか
かわりののない (プログラムやライブラリの) パス名や、 sudo フロントエンドのその他の設定
も、ここで指定することができる。
[訳注]: sudoers ファイルが、誰が何を実行できるかなどの sudoers セキュリティポリシーの設定
に使用されるのに対して、 sudo.conf ファイルは、 sudo コマンドが使用するセキュリ
ティポリシー・プラグインを特定したり、 どんなデバッグ情報を記録するかを指定したり
するなど、sudo フロントエンド、 すなわち sudo コマンドそのものの動作の設定に使用さ
れる。
sudo.conf では、次の命令 (directive) が使用できる。各命令については、 以下で詳しく説明す
る。
Plugin セキュリティポリシー・プラグインや入出力ロギング・プラグインを指定する
Path プラグインが何かにはかかわりのない (プログラムやライブラリの) パス
Set disable_coredump や group_source のようなフロントエンドの設定
Debug sudo, sudoreplay, visudo、及び sudoers プラグインのデバッグに使用するデバッグ・
フラグ
パウンド記号 ('#') は、コメントであることを示すために使用される。 コメントを示す記号とそれ
に続くテキストは、行末に至るまで無視される。
長い行は、行末にバックスラッシュ ('\') を置くことで、継続することができる。 行頭にあるホワ
イト・スペースは、行の継続を示す記号が使われている場合でも、 行頭から取り除かれることに注
意していただきたい。
コメント行以外でも、Plugin, Path, Debug, Set で始まっていない行は、無視される。 エラーや警
告メッセージを出すこともない。
sudo.conf ファイルの解析は、常に "C" ロケールで行われる。
プラグインの設定
sudo はセキュリティポリシーと入出力のロギングについて、プラグイン方式をサポートしている。
従って、サードパーティは、sudo のフロントエンドとシームレスに協働するポリシー・プラグイン
や、 入出力ロギング・プラグインを独自に開発して、配布することができる。 プラグイン
は、sudo.conf の記述に基づいて、動的にロードされる。
Plugin 行は、キーワード Plugin に始まり、symbol_name と path が続く。 path は、プラグイン
を含む動的共有オブジェクトへのパスである。 symbol_name は、プラグインに含まれる
policy_plugin 構造体や io_plugin 構造体のシンボル名である。path は絶対パスでも相対パスでも
よい。 相対パスの場合は、Path 命令の plugin_dir で指定したディレクトリを基点とする相対パス
であり、 デフォルトの基点は /usr/local/libexec/sudo である。すなわち、
Plugin sudoers_policy sudoers.so
は、次のものと同じだということだ。
Plugin sudoers_policy /usr/local/libexec/sudo/sudoers.so
プラグインが動的な共有オブジェクトとしてインストールされているのではなく、 sudo のバイナリ
に静的に組み込まれている場合は、 path にディレクトリまで指定してはいけない。 ファイルシス
テム中に実際に存在するわけではないからだ。 すなわち、こんなふうに指定する。
Plugin sudoers_policy sudoers.so
sudo 1.8.5 以降では、path の後ろにパラメータを付けると、それは、 プラグインの open 関数に
引き数として渡されるようになっている。たとえば、 コンパイル時に指定した sudoers ファイルの
デフォルトのモードを変更するには、 次のようにする。
Plugin sudoers_policy sudoers.so sudoers_mode=0440
使用できる引き数のリストについては、sudoers(5) のマニュアルをご覧いただきたい。
一つの動的な共有オブジェクトが、 それぞれ違ったシンボル名を持つ複数のプラグインを含んでい
ても構わない。 共有オブジェクト・ファイルは、uid 0 の所有でなければならず、 また、所有者の
み書き込み可能でなければならない。 同時に複数のポリシーがあると、曖昧さが生じるので、 ポリ
シー・プラグインは一つしか指定できない。 この制限は 入出力プラグインには当てはまらない。
sudo.conf ファイルが存在しない場合や、存在しても Plugin 行を含まない場合は、 デフォルトの
セキュリティポリシーとして sudoers プラグインが使用されることになる。 入出力ロギングにも
(ポリシーによって有効になっていれば)、 sudoers プラグインが使用される。これは次の記述と同
じことである。
Plugin sudoers_policy sudoers.so
Plugin sudoers_io sudoers.so
sudo プラグインの仕組みについてもっと詳しい情報が必要なら、 sudo_plugin(5) のマニュアルを
ご覧になっていただきたい。
パスの設定
Path 行は、キーワード Path に始まり、設定するパスの名称とその値が続く。 たとえば、次のよう
にだ。
Path noexec /usr/local/libexec/sudo/sudo_noexec.so
Path askpass /usr/X11R6/bin/ssh-askpass
パス名が (訳注: パスの名称ではなく、パスの値が) 指定されていない場合は、 その設定に依存す
る機能を無効化することになる。 パス設定の無効化をサポートしているのは、バージョン 1.8.16
以上の sudo だけである。
以下に挙げるような、 プラグインが何かにはかかわりのない (プログラムやライブラリの) パスを
/etc/sudo.conf で設定することができる。
askpass 端末が利用できないときに、ユーザのパスワードを読み込むのに使用するヘルパー・プロ
グラムの絶対パス。 たとえば、sudo がグラフィカルな (つまり、テキストベースではな
い) アプリケーションから実行される場合がこれに当たる。 askpass で指定されたプロ
グラムは、自分に渡された引き数をプロンプトとして表示し、 ユーザのパスワードを標
準出力に書き出すべきである。askpass の値は、 環境変数 SUDO_ASKPASS によって上書
きすることができる。
noexec ライブラリ関数 execl(), execle(), execlp(), exect(), execv(), execve(),
execvP(), execvp(), execvpe(), fexecve(), popen(), posix_spawn(),
posix_spawnp(), system() のダミー版 (単にエラーを返すだけの関数) が入っている共
有ライブラリの絶対パス。 これは LD_PRELOAD やそれに相当するものをサポートするシ
ステムで noexec 機能を実現するために使用される。デフォルトの値は
/usr/local/libexec/sudo/sudo_noexec.so である。
plugin_dir
絶対パスで指定されていないプラグインを捜すときに使用されるデフォルトのディレクト
リ。 デフォルトの値は /usr/local/libexec/sudo である
sesh sesh バイナリの絶対パス。この設定は、sudo が SELinux サポートを有効にしてビルド
されたときにのみ、使用される。 デフォルトの値は /usr/local/libexec/sudo/sesh で
ある。
その他の設定
sudo.conf ファイルでは、以下に挙げるフロントエンドの設定も行うことができる。
disable_coredump
デフォルトでは、セキュリティ上問題になるかもしれない情報を漏洩しないように、
sudo 自体のコアダンプは無効になっている。 sudo そのもののクラッシュをデバッグす
るためにコアダンプを有効に戻したいならば、 次のように、sudo.conf で
"disable_coredump" を false にすればよい。
Set disable_coredump false
最近のオペレーティング・システムでは、どのシステムでも、 sudo のような setuid プ
ロセスのコアダンプについて各種の制限を設けているので、 このオプションを有効にし
ても、セキュリティが弱体化することはない。 sudo のコアファイルを実際に得るために
は、 たぶん setuid プロセスに対するコアダンプを有効にする必要があるだろう。 BSD
や Linux のシステムでは、それは sysctl コマンドで行われる。 Solaris で
は、coreadm コマンドがコアダンプの動作設定に使用される。
この設定は、バージョン 1.8.4 以降の sudo でしか使用できない。
group_source
sudo は、起動したユーザが所属するグループのリストをポリシー・プラグインと 入出力
プラグインに引き渡す。ほとんどのシステムでは、 一人のユーザが同時に所属すること
のできるグループの数に上限がある (NFS との互換性のために、たいていは 16)。システ
ムに getconf(1) ユーティリティ・コマンドが存在するなら、
getconf NGROUPS_MAX
を実行すれば、グループの最大数がわかる。
しかしながら、ユーザが上限を越える数のグループのメンバーになることも可能である
-- 上限を越えた分は、そのユーザについてカーネルが返すグループのリストに含まれな
いだけのことだ。 バージョン 1.8.7 以降の sudo では、 ユーザについてカーネルが返
すグループのリストが所属グループの最大数に達しているときは、 sudo はグループ・
データベースを直接調べて、グループのリストを決定するようになっている。 そうする
ことによって、ユーザが所属グループの最大数よりも多くのグループのメンバーであると
きも、 セキュリティポリシーがグループ名によるマッチングを行うことができるように
しているのである。
group_source の設定によって、管理者がこのデフォルトの動作を変更することができ
る。 group_source に対して使用できる値は以下のものである。
static カーネルが返す static なグループ・リストを使用する。 グループ・リスト
をこの方法で取得するのは迅速だが、上で述べた上限を課されることになる。
この方法が "static (静的)" だというのは、ユーザがログインした後で行っ
た、 グループ・データベースに対する変更を反映しないからである。 これ
は、sudo 1.8.7 以前のデフォルトの動作だった。
dynamic 常にグループ・データベースに問い合わせる。この方法が "dynamic (動的)"
だというのは、ユーザがログインした後でグループ・データベースに行った変
更が、 グループのリストに反映するからである。システムによっては、 グ
ループ・データベースにユーザが所属するすべてのグループを問い合わせる
と、 非常に時間がかかることがある。 ネットワーク・ベースのグループ・
データベースに問い合わせる場合などがそうだ。 もっとも、たいていのオペ
レーティング・システムは、 そうした問い合わせを効率的に行う方法を用意
している。現在のところ、 sudo は、AIX, BSD, HP-UX, Linux, Solaris で効
率的なグループの問い合わせをサポートしている。
adaptive カーネルが返す static なグループのリストが、所属グループの最大数に達し
ているときにのみ、 グループ・データベースに問い合わせる。これが sudo
1.8.7 以降のデフォルトの動作である。
たとえば、sudo が、ユーザについてカーネルが返す static なグループのリストのみを
使うようにしたかったら、以下のように指定する。
Set group_source static
この設定は、バージョン 1.8.7 以降の sudo でしか使用できない。
max_groups
グループ・データベースから取得するユーザの所属グループの最大数。 1 未満の値は無
視されることになる。この設定が使用されるのは、 グループ・データベースに直接問い
合わせるときだけである。 グループのリストを入れることになっている配列が十分な大
きさを持っていない場合にも、 それを検出できないシステムが存在する。 この設定
は、そうしたシステムで使用することを目的にしている。 デフォルトでは、sudo はシス
テムが規定しているグループの最大数の (上記参照) 4 倍の配列を割り当て、グループ・
データベースへの問い合わせが失敗した場合は、 その数をさらに倍にして再実行するこ
とになっている。しかしながら、 システムの中には、配列に納まる数のグループを返す
だけで、 スペースが不足していてもエラーを知らせないものがあるのだ。
この設定は、バージョン 1.8.7 以降の sudo でしか使用できない。
probe_interfaces
デフォルトでは、sudo はシステムのネットワーク・インターフェースを調べて、 有効に
なっている各インターフェースの IP アドレスをポリシー・プラグインに伝える。 その
ため、プラグインは、DNS に問い合わせるまでもなく、 ルールを適用するかどうかを IP
アドレスに基づいて決めることができるわけだ。 Linux のシステムで多数のバーチャ
ル・インターフェースを使用している場合は、 この作業に無視できない時間がかかるか
もしれない。 IP アドレスに基づいたルールのマッチングが必要ないならば、 ネット
ワーク・インターフェースの検査を次のようにして無効にすることができる。
Set probe_interfaces false
この設定は、バージョン 1.8.10 以降の sudo でしか使用できない。
デバッグ・フラグ
バージョン 1.8.4 以上の sudo は、デバッグのための柔軟な枠組みに対応しており、 問題が生じた
ときに、sudo の内部で何が起きているかを突き止めるために、 それを利用することができる。
デバッグ行の構成は、Debug というキーワードに始まり、 デバッグ対象 (sudo, visudo,
sudoreplay, sudoers) のプログラム名、またはプラグイン名と、デバッグファイル名がそれに続
き、 最後にコンマで区切ったデバッグ・フラグのリストが来るという形になっている。 デバッグ・
フラグのシンタクスは、sudo と sudoers プラグインでは、 subsystem@priority という書式を用い
るが、コンマ (',') を含まないかぎり、別の書式を使用するプラグインがあっても構わない。
一例を挙げよう。
Debug sudo /var/log/sudo_debug all@warn,plugin@info
上記のように指定すると、warn レベル以上のすべてのデバッグ情報に加えて、 プラグイン・サブシ
ステムについては、info レベル以上の情報もログに記録することになる。
sudo 1.8.12 以来、一つのプログラムについて複数の Debug 行が指定できるようになっている。
sudo のそれ以前のバージョンでは、1 プログラムにつき 1 行の Debug 行しかサポートしていな
かった。sudo 1.8.12 からは、 プラグイン独自の Debug 行もサポートされるようになり、そうした
行のマッチングは、 ロードされているプラグインのベースネーム (たとえば、sudoers.so)、 また
はプラグインの絶対パス名によって行われる (訳注: 言い換えれば、 プラグイン独自の Debug 行で
は、プログラム名/プラグイン名の位置に Plugin 行における path の部分を指定するということだ
ろう)。以前のバージョンでは、 sudoers プラグインは、sudo フロントエンドと同じ Debug 行を共
有しており、別の設定をすることができなかった。
次の priority (重大度) が使用できる。深刻なものから挙げると、 crit, err, warn, notice,
diag, info, trace, debug である。 ある priority を指定すると、それよりも深刻なすべての
priority も指定したことになる。 たとえば、notice という priority を指定すれば、 notice レ
ベル以上のデバッグ情報がログに記録されるわけである。
trace と debug の priority では、ファンクション・コールのトレースも行われ、 関数に入ったと
きと関数から戻ったときのログも記録される。たとえば、 次のトレースは、src/sudo.c にある
get_user_groups() 関数に対するものである。
sudo[123] -> get_user_groups @ src/sudo.c:385
sudo[123] <- get_user_groups @ src/sudo.c:429 := groups=10,0,5
関数に入ったときは、右矢印 '->' で示され、プログラム名、プロセス ID、 関数名、ソースファイ
ルと行番号が記録される。 関数から戻ったときは、左矢印 '<-' で示され、同じ情報に加えて、 返
り値が記録される。上記の場合、返り値は文字列である。
sudo フロントエンドでは、以下のサブシステムが使用できる。
all すべてのサブシステムにマッチする
args コマンドライン引き数の処理
conv ユーザとのやりとり
edit sudoedit
event event サブシステム
exec コマンドの実行
main sudo のメイン関数
netif ネットワーク・インターフェースの取扱い
pcomm プラグインとのやりとり
plugin プラグインの設定
pty 擬似 tty 関連コード
selinux SELInux 特有の取扱い
util ユーティリティ関数群
utmp utmp の取扱い
sudoers(5) プラグインがサポートしているサブシステムには、これ以外のものもある。
ファイル
/etc/sudo.conf sudo フロントエンドの設定ファイル
用例
#
# Default /etc/sudo.conf file
#
# Format:
# Plugin plugin_name plugin_path plugin_options ...
# Path askpass /path/to/askpass
# Path noexec /path/to/sudo_noexec.so
# Debug sudo /var/log/sudo_debug all@warn
# Set disable_coredump true
#
# plugin_path が絶対パスでない場合は、/usr/local/libexec/sudo からの
# 相対パスである。
# plugin_name は、プラグイン中の、プラグインのインターフェース構造を
# 含むグローバル・シンボルと同じものである。
# plugin_options を指定するかしないかは、任意である。
#
# Plugin 行が存在しない場合、デフォルトの sudoers プラグインが
# 使用される。
Plugin sudoers_policy sudoers.so
Plugin sudoers_io sudoers.so
#
# Sudo askpass:
#
# askpass ヘルパー・プログラムを指定すると、sudo の "-A" オプションで
# 使用できるように、グラフィカルなパスワード・プロンプトを用意する
# ことができる。sudo は、自前の askpass プログラムを配布していないが、
# たとえば、OpenSSH の askpass を使用することが可能だ。
#
# OpenSSH askpass を使用する。
#Path askpass /usr/X11R6/bin/ssh-askpass
#
# Gnome の OpenSSH askpass を使用する。
#Path askpass /usr/libexec/openssh/gnome-ssh-askpass
#
# Sudo noexec:
#
# ライブラリ関数 execv(), execve(), fexecve() のダミー版 (単にエラー
# を返すだけの関数) が入っている共有ライブラリのパス。この指定は、
# <LD_PRELOAD> やそれに相当するものをサポートしているシステムで
# "noexec" 機能を実現するために使用される。たいていの場合、
# コンパイル時に組み込まれた値で十分であり、変更するのは、
# sudo_noexec.so ファイルをリネームしたり、移動したりしたときのみに
# するべきである。
#
#Path noexec /usr/local/libexec/sudo/sudo_noexec.so
#
# Core dumps:
#
# sudo はデフォルトでは、自己を実行中のコアダンプを抑止している
# (指定されたコマンドを実行するときに、コアダンプを有効にし直す
# のだ)。sudo 自体の問題をデバッグするために、コアダンプを有効に
# 戻したいならば、"disable_coredump" を false にすればよい。
#
#Set disable_coredump false
#
# User groups:
#
# sudo は、ユーザが属するグループのリストをポリシー・プラグインに
# 引き渡す。ユーザの所属グループが、所属グループの最大数 (たいていは
# 16) に達している場合は、sudo は、そのユーザが所属するグループを
# すべて取得するため、直接グループ・データベースに問い合わせを行う。
#
# システムによっては、この動作は負担がかかることがあるので、設定に
# よって変更できるようになっている。"group_source" で設定できる
# 値には、三つのものがある。
# static - ユーザが属するグループのリストにカーネルが返したものを
# 使用する。
# dynamic - グループのリストを知るために、グループ・データベースに
# 問い合わせる。
# adaptive - ユーザの所属グループが、所属グループの最大数より少ない
# ときは、カーネルの返すリストを使う。さもなければ、
# グループ・データベースに問い合わせる。
#
#Set group_source static
関連項目
sudoers(5), sudo(8), sudo_plugin(5)
履歴
sudo の簡単な履歴については、sudo の配布に含まれている HISTORY ファイルをご覧いただきた
い。 (https://www.sudo.ws/history.html)
作者
多数の人々が長年に渡って sudo の開発に携わってきた。 当バージョンは主として次の者が書いた
コードからできている。
Todd C. Miller
sudo の開発に貢献してくださった方々の詳細なリストについては、 配布物中の CONTRIBUTORS ファ
イルをご覧になっていただきたい。 (https://www.sudo.ws/contributors.html)
バグ
sudo にバグを発見したと思ったら、https://www.sudo.ws/ にアクセスして、バグレポートを提出し
ていただきたい。
サポート
ある程度の無料サポートが sudo-users メーリングリストを通して利用できる。 購読やアーカイブ
の検索には、次の URL を御覧になるとよい。 https://www.sudo.ws/mailman/listinfo/sudo-users
免責
sudo は「現状のまま」提供される。 明示的な、あるいは黙示的ないかなる保証も、 商品性や特定
目的への適合性についての黙示的な保証を含め、 またそれのみに止まらず、これを否認する。詳細
な全文については、 sudo と一緒に配布されている LICENSE ファイルや、 次の Web ページをご覧
いただきたい。 https://www.sudo.ws/license.html