.\" DO NOT EDIT THIS FILE, IT IS NOT THE MASTER!
.\" IT IS GENERATED AUTOMATICALLY FROM sudo.conf.mdoc.in
.\"
.\" Copyright (c) 2010-2016 Todd C. Miller <Todd.Miller@courtesan.com>
.\"
.\" Permission to use, copy, modify, and distribute this software for any
.\" purpose with or without fee is hereby granted, provided that the above
.\" copyright notice and this permission notice appear in all copies.
.\"
.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
.\" ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
.\"
.\"*******************************************************************
.\"
.\" This file was generated with po4a. Translate the source file.
.\"
.\"*******************************************************************
.\"
.\" Japanese Version Copyright (c) 2016 Yoichi Chonan
.\"         all rights reserved.
.\" Translated (sudo-1.8.17) Sat Sep 10 10:39:07 JST 2016
.\"         by Yoichi Chonan <cyoichi@maple.ocn.ne.jp>
.\"
.TH SUDO.CONF 5 "June 15, 2016" "Sudo 1.8.17" "File Formats Manual"
.nh
.if  n .ad l
.SH 名前
\fBsudo.conf\fP \- sudo フロントエンドの設定
.SH 説明
\fBsudo.conf\fP ファイルは、\fBsudo\fP フロントエンドの設定に使用される。
セキュリティポリシー・プラグイン、入出力ロギング・プラグイン、
デバッグ・フラグの指定をはじめ、
プラグインが何かにはかかわりののない (プログラムやライブラリの) パス名や、
\fBsudo\fP フロントエンドのその他の設定も、ここで指定することができる。
.IP "[\fB訳注\fP]:" 8
sudoers ファイルが、誰が何を実行できるかなどの 
\fBsudoers\fP セキュリティポリシーの設定に使用されるのに対して、
sudo.conf ファイルは、
\fBsudo\fP コマンドが使用するセキュリティポリシー・プラグインを特定したり、
どんなデバッグ情報を記録するかを指定したりするなど、\fBsudo\fP フロントエンド、
すなわち \fBsudo\fP コマンドそのものの動作の設定に使用される。
.PP
\fBsudo.conf\fP では、次の命令 (directive) が使用できる。各命令については、
以下で詳しく説明する。
.TP  10n
Plugin
セキュリティポリシー・プラグインや入出力ロギング・プラグインを指定する
.TP  10n
Path
プラグインが何かにはかかわりのない (プログラムやライブラリの) パス
.TP  10n
Set
\fIdisable_coredump\fP や \fIgroup_source\fP のようなフロントエンドの設定
.TP  10n
Debug
\fBsudo\fP, \fBsudoreplay\fP, \fBvisudo\fP、及び \fBsudoers\fP
プラグインのデバッグに使用するデバッグ・フラグ
.PP
パウンド記号 ('#') は、コメントであることを示すために使用される。
コメントを示す記号とそれに続くテキストは、行末に至るまで無視される。
.PP
長い行は、行末にバックスラッシュ ('\e') を置くことで、継続することができる。
行頭にあるホワイト・スペースは、行の継続を示す記号が使われている場合でも、
行頭から取り除かれることに注意していただきたい。
.PP
コメント行以外でも、Plugin, Path, Debug, Set で始まっていない行は、無視される。
エラーや警告メッセージを出すこともない。
.PP
\fBsudo.conf\fP ファイルの解析は、常に "C" ロケールで行われる。
.SS プラグインの設定
\fBsudo\fP はセキュリティポリシーと入出力のロギングについて、プラグイン方式をサポートしている。
従って、サードパーティは、\fBsudo\fP のフロントエンドとシームレスに協働するポリシー・プラグインや、
入出力ロギング・プラグインを独自に開発して、配布することができる。
プラグインは、\fBsudo.conf\fP の記述に基づいて、動的にロードされる。
.PP
Plugin 行は、キーワード Plugin に始まり、\fIsymbol_name\fP と \fIpath\fP が続く。
\fIpath\fP は、プラグインを含む動的共有オブジェクトへのパスである。
\fIsymbol_name\fP は、プラグインに含まれる policy_plugin 構造体や
io_plugin 構造体のシンボル名である。\fIpath\fP は絶対パスでも相対パスでもよい。
相対パスの場合は、Path 命令の \fIplugin_dir\fP で指定したディレクトリを基点とする相対パスであり、
デフォルトの基点は \fI/usr/local/libexec/sudo\fP である。すなわち、
.nf
.sp
.RS 6n
Plugin sudoers_policy sudoers.so
.RE
.fi
.PP
は、次のものと同じだということだ。
.nf
.sp
.RS 6n
Plugin sudoers_policy /usr/local/libexec/sudo/sudoers.so
.RE
.fi
.PP
プラグインが動的な共有オブジェクトとしてインストールされているのではなく、
\fBsudo\fP のバイナリに静的に組み込まれている場合は、
\fIpath\fP にディレクトリまで指定してはいけない。
ファイルシステム中に実際に存在するわけではないからだ。
すなわち、こんなふうに指定する。
.nf
.sp
.RS 6n
Plugin sudoers_policy sudoers.so
.RE
.fi
.PP
\fBsudo\fP 1.8.5 以降では、\fIpath\fP の後ろにパラメータを付けると、それは、
プラグインの \fIopen\fP 関数に引き数として渡されるようになっている。たとえば、
コンパイル時に指定した sudoers ファイルのデフォルトのモードを変更するには、
次のようにする。
.nf
.sp
.RS 6n
Plugin sudoers_policy sudoers.so sudoers_mode=0440
.RE
.fi
.PP
使用できる引き数のリストについては、sudoers(5) のマニュアルをご覧いただきたい。
.PP
一つの動的な共有オブジェクトが、
それぞれ違ったシンボル名を持つ複数のプラグインを含んでいても構わない。
共有オブジェクト・ファイルは、uid 0 の所有でなければならず、
また、所有者のみ書き込み可能でなければならない。
同時に複数のポリシーがあると、曖昧さが生じるので、
ポリシー・プラグインは一つしか指定できない。
この制限は 入出力プラグインには当てはまらない。
.PP
\fBsudo.conf\fP ファイルが存在しない場合や、存在しても Plugin 行を含まない場合は、
デフォルトのセキュリティポリシーとして \fBsudoers\fP プラグインが使用されることになる。
入出力ロギングにも (ポリシーによって有効になっていれば)、
\fBsudoers\fP プラグインが使用される。これは次の記述と同じことである。
.nf
.sp
.RS 6n
Plugin sudoers_policy sudoers.so
Plugin sudoers_io sudoers.so
.RE
.fi
.PP
\fBsudo\fP プラグインの仕組みについてもっと詳しい情報が必要なら、
sudo_plugin(5) のマニュアルをご覧になっていただきたい。
.SS パスの設定
Path 行は、キーワード Path に始まり、設定するパスの名称とその値が続く。
たとえば、次のようにだ。
.nf
.sp
.RS 6n
Path noexec /usr/local/libexec/sudo/sudo_noexec.so
Path askpass /usr/X11R6/bin/ssh\-askpass
.RE
.fi
.PP
パス名が (訳注: パスの名称ではなく、パスの値が) 指定されていない場合は、
その設定に依存する機能を無効化することになる。
パス設定の無効化をサポートしているのは、バージョン 1.8.16 以上の \fBsudo\fP だけである。
.PP
以下に挙げるような、
プラグインが何かにはかかわりのない (プログラムやライブラリの) パスを
\fI/etc/sudo.conf\fP で設定することができる。
.TP  10n
askpass
端末が利用できないときに、ユーザのパスワードを読み込むのに使用するヘルパー・プログラムの絶対パス。
たとえば、\fBsudo\fP がグラフィカルな (つまり、テキストベースではない)
アプリケーションから実行される場合がこれに当たる。
\fIaskpass\fP で指定されたプログラムは、自分に渡された引き数をプロンプトとして表示し、
ユーザのパスワードを標準出力に書き出すべきである。\fIaskpass\fP の値は、
環境変数 SUDO_ASKPASS によって上書きすることができる。
.TP  10n
noexec
ライブラリ関数 \fBexecl\fP(), \fBexecle\fP(), \fBexeclp\fP(), \fBexect\fP(), \fBexecv\fP(),
\fBexecve\fP(), \fBexecvP\fP(), \fBexecvp\fP(), \fBexecvpe\fP(), \fBfexecve\fP(),
\fBpopen\fP(), \fBposix_spawn\fP(), \fBposix_spawnp\fP(), \fBsystem\fP() のダミー版
(単にエラーを返すだけの関数) が入っている共有ライブラリの絶対パス。
これは LD_PRELOAD やそれに相当するものをサポートするシステムで
\fInoexec\fP 機能を実現するために使用される。デフォルトの値は
\fI/usr/local/libexec/sudo/sudo_noexec.so\fP である。
.TP  10n
plugin_dir
絶対パスで指定されていないプラグインを捜すときに使用されるデフォルトのディレクトリ。
デフォルトの値は \fI/usr/local/libexec/sudo\fP である
.TP  10n
sesh
\fBsesh\fP バイナリの絶対パス。この設定は、\fBsudo\fP が SELinux
サポートを有効にしてビルドされたときにのみ、使用される。
デフォルトの値は \fI/usr/local/libexec/sudo/sesh\fP である。
.SS その他の設定
\fBsudo.conf\fP ファイルでは、以下に挙げるフロントエンドの設定も行うことができる。
.TP  10n
disable_coredump
デフォルトでは、セキュリティ上問題になるかもしれない情報を漏洩しないように、
\fBsudo\fP 自体のコアダンプは無効になっている。
\fBsudo\fP そのもののクラッシュをデバッグするためにコアダンプを有効に戻したいならば、
次のように、\fBsudo.conf\fP で "disable_coredump" を false にすればよい。
.nf
.sp
.RS 16n
Set disable_coredump false
.RE
.fi
.RS 10n
.sp
最近のオペレーティング・システムでは、どのシステムでも、
\fBsudo\fP のような setuid プロセスのコアダンプについて各種の制限を設けているので、
このオプションを有効にしても、セキュリティが弱体化することはない。
\fBsudo\fP のコアファイルを実際に得るためには、
たぶん setuid プロセスに対するコアダンプを有効にする必要があるだろう。
BSD や Linux のシステムでは、それは sysctl コマンドで行われる。
Solaris では、coreadm コマンドがコアダンプの動作設定に使用される。
.sp
この設定は、バージョン 1.8.4 以降の \fBsudo\fP でしか使用できない。
.RE
.TP  10n
group_source
\fBsudo\fP は、起動したユーザが所属するグループのリストをポリシー・プラグインと
入出力プラグインに引き渡す。ほとんどのシステムでは、
一人のユーザが同時に所属することのできるグループの数に上限がある (NFS
との互換性のために、たいていは 16)。システムに getconf(1)
ユーティリティ・コマンドが存在するなら、
.RS 16n
getconf NGROUPS_MAX
.RE
.RS 10n
を実行すれば、グループの最大数がわかる。
.sp
しかしながら、ユーザが上限を越える数のグループのメンバーになることも可能である \-\-
上限を越えた分は、そのユーザについてカーネルが返すグループのリストに含まれないだけのことだ。
バージョン 1.8.7 以降の \fBsudo\fP では、
ユーザについてカーネルが返すグループのリストが所属グループの最大数に達しているときは、
\fBsudo\fP はグループ・データベースを直接調べて、グループのリストを決定するようになっている。
そうすることによって、ユーザが所属グループの最大数よりも多くのグループのメンバーであるときも、
セキュリティポリシーがグループ名によるマッチングを行うことができるようにしているのである。
.sp
\fIgroup_source\fP の設定によって、管理者がこのデフォルトの動作を変更することができる。
\fIgroup_source\fP に対して使用できる値は以下のものである。
.TP  10n
static
カーネルが返す static なグループ・リストを使用する。
グループ・リストをこの方法で取得するのは迅速だが、上で述べた上限を課されることになる。
この方法が "static (静的)" だというのは、ユーザがログインした後で行った、
グループ・データベースに対する変更を反映しないからである。
これは、\fBsudo\fP 1.8.7 以前のデフォルトの動作だった。
.TP  10n
dynamic
常にグループ・データベースに問い合わせる。この方法が "dynamic (動的)"
だというのは、ユーザがログインした後でグループ・データベースに行った変更が、
グループのリストに反映するからである。システムによっては、
グループ・データベースにユーザが所属するすべてのグループを問い合わせると、
非常に時間がかかることがある。
ネットワーク・ベースのグループ・データベースに問い合わせる場合などがそうだ。
もっとも、たいていのオペレーティング・システムは、
そうした問い合わせを効率的に行う方法を用意している。現在のところ、
\fBsudo\fP は、AIX, BSD, HP\-UX, Linux, Solaris
で効率的なグループの問い合わせをサポートしている。
.TP  10n
adaptive
カーネルが返す static なグループのリストが、所属グループの最大数に達しているときにのみ、
グループ・データベースに問い合わせる。これが \fBsudo\fP 1.8.7 以降のデフォルトの動作である。
.PP
たとえば、\fBsudo\fP が、ユーザについてカーネルが返す static
なグループのリストのみを使うようにしたかったら、以下のように指定する。
.nf
.sp
.RS 16n
Set group_source static
.RE
.fi
.sp
この設定は、バージョン 1.8.7 以降の \fBsudo\fP でしか使用できない。
.RE
.TP  10n
max_groups
グループ・データベースから取得するユーザの所属グループの最大数。
1 未満の値は無視されることになる。この設定が使用されるのは、
グループ・データベースに直接問い合わせるときだけである。
グループのリストを入れることになっている配列が十分な大きさを持っていない場合にも、
それを検出できないシステムが存在する。
この設定は、そうしたシステムで使用することを目的にしている。
デフォルトでは、\fBsudo\fP はシステムが規定しているグループの最大数の (上記参照)
4 倍の配列を割り当て、グループ・データベースへの問い合わせが失敗した場合は、
その数をさらに倍にして再実行することになっている。しかしながら、
システムの中には、配列に納まる数のグループを返すだけで、
スペースが不足していてもエラーを知らせないものがあるのだ。
.sp
この設定は、バージョン 1.8.7 以降の \fBsudo\fP でしか使用できない。
.TP  10n
probe_interfaces
デフォルトでは、\fBsudo\fP はシステムのネットワーク・インターフェースを調べて、
有効になっている各インターフェースの IP アドレスをポリシー・プラグインに伝える。
そのため、プラグインは、DNS に問い合わせるまでもなく、
ルールを適用するかどうかを IP アドレスに基づいて決めることができるわけだ。
Linux のシステムで多数のバーチャル・インターフェースを使用している場合は、
この作業に無視できない時間がかかるかもしれない。
IP アドレスに基づいたルールのマッチングが必要ないならば、
ネットワーク・インターフェースの検査を次のようにして無効にすることができる。
.nf
.sp
.RS 16n
Set probe_interfaces false
.RE
.fi
.RS 10n
.sp
この設定は、バージョン 1.8.10 以降の \fBsudo\fP でしか使用できない。
.RE
.SS デバッグ・フラグ
バージョン 1.8.4 以上の \fBsudo\fP は、デバッグのための柔軟な枠組みに対応しており、
問題が生じたときに、\fBsudo\fP の内部で何が起きているかを突き止めるために、
それを利用することができる。
.PP
デバッグ行の構成は、Debug というキーワードに始まり、
デバッグ対象 (\fBsudo\fP, \fBvisudo\fP, \fBsudoreplay\fP, \fBsudoers\fP)
のプログラム名、またはプラグイン名と、デバッグファイル名がそれに続き、
最後にコンマで区切ったデバッグ・フラグのリストが来るという形になっている。
デバッグ・フラグのシンタクスは、\fBsudo\fP と \fBsudoers\fP プラグインでは、
\fIsubsystem\fP@\fIpriority\fP という書式を用いるが、コンマ ('\&,')
を含まないかぎり、別の書式を使用するプラグインがあっても構わない。
.PP
一例を挙げよう。
.nf
.sp
.RS 6n
Debug sudo /var/log/sudo_debug all@warn,plugin@info
.RE
.fi
.PP
上記のように指定すると、\fIwarn\fP レベル以上のすべてのデバッグ情報に加えて、
プラグイン・サブシステムについては、\fIinfo\fP レベル以上の情報もログに記録することになる。
.PP
\fBsudo\fP 1.8.12 以来、一つのプログラムについて複数の
Debug 行が指定できるようになっている。
\fBsudo\fP のそれ以前のバージョンでは、1 プログラムにつき
1 行の Debug 行しかサポートしていなかった。\fBsudo\fP 1.8.12 からは、
プラグイン独自の Debug 行もサポートされるようになり、そうした行のマッチングは、
ロードされているプラグインのベースネーム (たとえば、sudoers.so)、
またはプラグインの絶対パス名によって行われる (訳注: 言い換えれば、
プラグイン独自の Debug 行では、プログラム名/プラグイン名の位置に
Plugin 行における \fIpath\fP の部分を指定するということだろう)。以前のバージョンでは、
\fBsudoers\fP プラグインは、\fBsudo\fP フロントエンドと同じ
Debug 行を共有しており、別の設定をすることができなかった。
.PP
次の priority (重大度) が使用できる。深刻なものから挙げると、
\fIcrit\fP, \fIerr\fP, \fIwarn\fP, \fInotice\fP, \fIdiag\fP, \fIinfo\fP, \fItrace\fP, \fIdebug\fP
である。
ある priority を指定すると、それよりも深刻なすべての priority も指定したことになる。
たとえば、\fInotice\fP という priority を指定すれば、
\fInotice\fP レベル以上のデバッグ情報がログに記録されるわけである。
.PP
\fItrace\fP と \fIdebug\fP の priority では、ファンクション・コールのトレースも行われ、
関数に入ったときと関数から戻ったときのログも記録される。たとえば、
次のトレースは、src/sudo.c にある get_user_groups() 関数に対するものである。
.nf
.sp
.RS 6n
sudo[123] \-> get_user_groups @ src/sudo.c:385
sudo[123] <\- get_user_groups @ src/sudo.c:429 := groups=10,0,5
.RE
.fi
.PP
関数に入ったときは、右矢印 '\->' で示され、プログラム名、プロセス ID、
関数名、ソースファイルと行番号が記録される。
関数から戻ったときは、左矢印 '<\-' で示され、同じ情報に加えて、
返り値が記録される。上記の場合、返り値は文字列である。
.PP
\fBsudo\fP フロントエンドでは、以下のサブシステムが使用できる。
.TP  12n
\fIall\fP
すべてのサブシステムにマッチする
.TP  12n
\fIargs\fP
コマンドライン引き数の処理
.TP  12n
\fIconv\fP
ユーザとのやりとり
.TP  12n
\fIedit\fP
sudoedit
.TP  12n
\fIevent\fP
event サブシステム
.TP  12n
\fIexec\fP
コマンドの実行
.TP  12n
\fImain\fP
\fBsudo\fP のメイン関数
.TP  12n
\fInetif\fP
ネットワーク・インターフェースの取扱い
.TP  12n
\fIpcomm\fP
プラグインとのやりとり
.TP  12n
\fIplugin\fP
プラグインの設定
.TP  12n
\fIpty\fP
擬似 tty 関連コード
.TP  12n
\fIselinux\fP
SELInux 特有の取扱い
.TP  12n
\fIutil\fP
ユーティリティ関数群
.TP  12n
\fIutmp\fP
utmp の取扱い
.PP
sudoers(5) プラグインがサポートしているサブシステムには、これ以外のものもある。
.SH ファイル
.TP  26n
\fI/etc/sudo.conf\fP
\fBsudo\fP フロントエンドの設定ファイル
.SH 用例
.nf
.RS 0n
#
# 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
.RE
.fi
.SH 関連項目
sudoers(5), sudo(8), sudo_plugin(5)
.SH 履歴
sudo の簡単な履歴については、\fBsudo\fP の配布に含まれている
HISTORY ファイルをご覧いただきたい。
(https://www.sudo.ws/history.html)
.SH 作者
多数の人々が長年に渡って \fBsudo\fP の開発に携わってきた。
当バージョンは主として次の者が書いたコードからできている。
.sp
.RS 6n
Todd C. Miller
.RE
.PP
\fBsudo\fP の開発に貢献してくださった方々の詳細なリストについては、
配布物中の CONTRIBUTORS ファイルをご覧になっていただきたい。
(https://www.sudo.ws/contributors.html)
.SH バグ
\fBsudo\fP にバグを発見したと思ったら、https://www.sudo.ws/
にアクセスして、バグレポートを提出していただきたい。
.SH サポート
ある程度の無料サポートが sudo\-users メーリングリストを通して利用できる。
購読やアーカイブの検索には、次の URL を御覧になるとよい。
https://www.sudo.ws/mailman/listinfo/sudo\-users
.SH 免責
\fBsudo\fP は「現状のまま」提供される。 明示的な、あるいは黙示的ないかなる保証も、
商品性や特定目的への適合性についての黙示的な保証を含め、
またそれのみに止まらず、これを否認する。詳細な全文については、
\fBsudo\fP と一緒に配布されている LICENSE ファイルや、
次の Web ページをご覧いただきたい。
https://www.sudo.ws/license.html