| SUDOERS.LDAP(5) | File Formats Manual | SUDOERS.LDAP(5) |
sudoers.ldap - LDAP を使用した sudoers ポリシーの設定
sudoers セキュリティポリシーは sudoers ファイルによって設定するのが標準だが、 LDAP を通して設定することもできる。この方法は、大規模な分散環境で sudoers セキュリティポリシーの設定を同期させたい場合に、 とりわけ便利かもしれない。
sudoers セキュリティポリシーの設定に LDAP を使用すると、有利な点がいくつかある。
LDAP による設定と sudoers ファイルによる設定との、もう一つの大きな違いは、 LDAP では sudo 専用のエイリアスがサポートされていないことである。
たいていの場合、sudo 専用のエイリアスは実のところ必要がない。 User_Aliases や Runas_Aliases の代わりに、 Unix のグループ、non-Unix グループ (group_plugin を介して)、 ユーザのネットグループが使用できる。 また、Host_Aliases の代わりには、ホストのネットグループが使える。 LDAP には グループやネットグループも格納できるので、 sudo 専用のエイリアスがどうしても必要というわけではないのだ。
Cmnd_Aliases もまったく必要がない。 一つの sudoRole エントリに複数のユーザを登録できるからだ。 複数のユーザが参照する Cmnd_Alias を定義する代わりに、 複数のコマンドを含む sudoRole エントリを一つ作成して、 そこに複数のユーザを割り当てればよい。
LDAP では、sudoers セキュリティポリシーの設定は ou=SUDOers コンテナの下に配置されている。
dn: ou=SUDOers,dc=example,dc=com objectClass: top objectClass: organizationalUnit ou: SUDOers
sudo はまず最初に SUDOers コンテナ配下に cn=defaults のエントリを捜す。 見つかった場合は、複数回指定可能な sudoOption 属性が、/etc/sudoers のグローバルな Defaults 行と同じやり方で解析される。以下の例では、 環境変数 SSH_AUTH_SOCK がすべてのユーザの環境に保存されることになる。
dn: cn=defaults,ou=SUDOers,dc=example,dc=com objectClass: top objectClass: sudoRole cn: defaults description: Default sudoOption's go here sudoOption: env_keep+=SSH_AUTH_SOCK
LDAP において /etc/sudoers の個々の「ユーザ設定」に相当するのは、 sudoRole エントリである。それは以下の属性からなっている。
コマンド名として組み込みコマンドの "sudoedit" を使用すれば、 ユーザが sudo を -e オプション付きで (あるいは、sudoedit の名前で) 実行するのを許可することになる。普通のコマンドの場合と同じように、 コマンドライン引数まで指定してもよい。"sudoedit" は sudo 本体に組み込まれたコマンドなので、これをコマンド名に指定するときは、 頭にパスをつけてはいけないことに注意していただきたい。
ALL という特別な値は、いかなるコマンドにもマッチする。
コマンド名の前に SHA-2 ダイジェストが付いていると、実行が許可されるのは、 ダイジェストがマッチしたときだけになる。これは、sudo を実行するユーザが、 対象となるコマンドやその親ディレクトリに書き込み権限を持っているような場合に、 役に立つだろう。ダイジェストのフォーマットとしては、sha224, sha256, sha384, sha512 がサポートされている。ダイジェスト名の後ろにはコロン (':') を置いて、その後に実際のダイジェストを続けなければならない。 ダイジェストは、16 進数でも base64 形式でもよい。 たとえば、sudoCommand に対して以下の値を指定すると、
sha224:0GomF8mNN3wlDt1HD9XldjJ3SNgpFdbjO1+NsQ /bin/ls
ユーザが /bin/ls を実行できるのは、/bin/ls の sha224 ダイジェストが指定した値とマッチしたときだけになる。 コマンドのダイジェストをサポートしているのは、バージョン 1.8.7 以上だけである。
属性 sudoRunAsUser は、バージョン 1.7.0 以上の sudo でなければ、 利用できない。それ以前のバージョンの sudo では、 代わりに属性 sudoRunAs を使用している。
属性 sudoRunAsGroup は、バージョン 1.7.0 以上の sudo でなければ、 利用できない。
属性 sudoNotBefore は、バージョン 1.7.5 以上の sudo でなければ、 利用できない。また、/etc/ldap.conf の SUDOERS_TIMED オプションで明示的に有効にする必要がある。
属性 sudoNotAfter は、バージョン 1.7.5 以上の sudo でなければ、 利用できない。また、/etc/ldap.conf の SUDOERS_TIMED オプションで明示的に有効にする必要がある。
属性 sudoOrder は、バージョン 1.7.5 以上の sudo でなければ、 利用できない。
上記の各属性は単一の値を持つべきだが、同じタイプの属性が複数回現れても構わない。 sudoRole エントリは、sudoUser、sudoHost、sudoCommand を、 少なくともそれぞれ一個は含んでいなければならない。
次の例では、wheel グループのユーザに sudo 経由でいかなるホストでも任意のコマンドの実行を許可している。
dn: cn=%wheel,ou=SUDOers,dc=example,dc=com objectClass: top objectClass: sudoRole cn: %wheel sudoUser: %wheel sudoHost: ALL sudoCommand: ALL
LDAP を使って、あるユーザに関する sudoers セキュリティポリシーを照合するとき、 LDAP の問い合わせは sudo の実行ごとにたった二回か三回行われるだけである。 一回目の問い合わせは、グローバル・オプションを解析するために行われる。 二回目の問い合わせは、sudo を実行するユーザのユーザ名や、 所属グループに対応するエントリを見つけるためだ (特別なタグ ALL が何にでもマッチするのは、この場合も同様である)。 ユーザ名やグループに対応するエントリが得られなかった場合は、 三回目の問い合わせが行われ、ユーザのネットグループや non-Unix グループを含んでいるすべてのエントリーを取得して、 問題のユーザがそのどれかに属していないかをチェックする。
/etc/ldap.conf の設定オプション SUDOERS_TIMED を有功にして、 エントリの日時制限を使えるようにしている場合は、 LDAP の問い合わせにサブフィルターによる選別が伴うことになる。 そのサブフィルターが、日時制限が存在するエントリについては、 その制限を満たしているエントリのみに、情報の検索を限定するのである。
NETGROUP_BASE 設定オプションが使用されている場合は (下記の 「ldap.conf の設定」を参照)、 ユーザがどことどこのネットグループに所属しているかを調べるための問い合わせが、 sudoers セキュリティポリシー設定の問い合わせの前に行われる。 そうすることで、セキュリティポリシー設定の問い合わせに使う文字列に、 ネットグループを Unix グループと同じように使うことが可能になるのだ。 上で述べた三回目の問い合わせは、 グループ・プロバイダー・プラグインも同時に設定されていないかぎり、行われない。 ネットグループについての sudo による LDAP の問い合わせは、 実際には次のように行われる。
多数のネットグループを持つサイトでは、NETGROUP_BASE を使用すると、 sudo の実行速度を大幅に向上させることができる。
LDAP を使用した場合は、sudoers セキュリティポリシー設定の処理方法に /etc/sudoers の場合とは微妙な違いがいくつかある。たぶん最大の違いは、 RFC に書いてあるとおり、LDAP の順序づけは不定なので、 属性やエントリが何らかの決まった順序で返されることを期待できないことだろう。
それでも、個々のエントリに割り振られる順番については、sudoOrder によってコントロールすることができる。 だが、ある特定のエントリ内での属性の順番については、 それを確定する方法は存在しないのだ。 もっとも、あるエントリーにコマンドに関して相反するルールがある場合は、 否定する方が優先される。いわゆるパラノイア的動作である (それが一番すっきりしたマッチだとはかぎらないが)。
例を挙げてみよう。
# /etc/sudoers の場合: # shell 以外のすべてのコマンドを許可する johnny ALL=(root) ALL,!/bin/sh # 次の設定は、ALL が最後にマッチするので、常にすべての # コマンドを許可することになる puddles ALL=(root) !/bin/sh,ALL # 上記の johnny に相当する LDAP のエントリ: # shell 以外のすべてのコマンドを許可する dn: cn=role1,ou=Sudoers,dc=my-domain,dc=com objectClass: sudoRole objectClass: top cn: role1 sudoUser: johnny sudoHost: ALL sudoCommand: ALL sudoCommand: !/bin/sh # 上記の puddles に相当する LDAP のエントリ: # ALL が最後に指定されているが、LDAP のコードでは、 # よりパラノイア的な方を、指定された設定と見なすようになって # いるため、これもまた role1 と同じように動作することに # 注意していただきたい dn: cn=role2,ou=Sudoers,dc=my-domain,dc=com objectClass: sudoRole objectClass: top cn: role2 sudoUser: puddles sudoHost: ALL sudoCommand: !/bin/sh sudoCommand: ALL
もう一つの相違は、Host、User、Runas についての否定は、 現在のところ無視されるということだ。 たとえば、以下に挙げるような属性は期待どおりに動作しない。
# joe 以外の全員とマッチしないどころか、 # 誰にもマッチしない sudoUser: !joe # joe 以外の全員とマッチしないどころか、 # joe を含む全員にマッチしてしまう sudoUser: ALL sudoUser: !joe # web01 以外のすべてとマッチしないどころか、 # web01 を含むすべてのホストにマッチしてしまう sudoHost: ALL sudoHost: !web01
sudo の LDAP サポートを利用するためには、お使いの LDAP サーバに sudo 用のスキーマをインストールしなければならない。 そして、sudoUser 属性の索引を必ず作成しておく。
たぶん、sudo の配布物中には三種類のスキーマが入っていると思う。 すなわち OpenLDAP サーバ用 (schema.OpenLDAP)、 Netscape ディレクトリサーバの流れを汲むサーバ用 (schema.iPlanet)、 Microsoft Active Directory 用 (schema.ActiveDirectory) のスキーマである。
OpenLDAP 用の形式にした sudo のスキーマは、 「用例」セクションにも記載しておいた。
sudo は LDAP に関する設定を知るために /etc/ldap.conf を読み込む。 通例、このファイルは、 LDAP に対応しているさまざまなクライアントの間で共有されている。 それ故、設定の大部分は sudo 専用ではない。 注意すべきは、sudo は /etc/ldap.conf を独自に解析しており、 ldap.conf(5) のマニュアルで説明されているものとは 異なるオプションをサポートしていることがあるということだ。 ldap.conf のパスは、sudo.conf(5) ファイルでプラグインに対する引き数 ldap_conf を使用すれば、変更することができる (訳注: sudoers ポリシー・プラグインに対して指定できる引き数については、 sudoers(5) のマニュアルの「sudoers ポリシー・プラグインを使うための sudo.conf の設定」セクションに説明がある)。
もうひとつ注意していただきたいのは、 OpenLDAP ライブラリを使っているシステムでは、 /etc/openldap/ldap.conf やユーザの .ldaprc ファイルで指定しているデフォルト値が使用されないことである。
すなわち、/etc/ldap.conf に明示的に記載され、かつ sudo でサポートされているオプションのみが使用される。 設定オプションを以下に大文字で列挙するが、 解析されるときは大文字小文字は区別されない。
パウンド記号 ('#') を使用すれば、 以下はコメントであると示すことができる。すなわち、 コメントの印と、それに続くいかなるテキストも、行末に至るまで、 無視されることになる。長い行は、行末にバックスラッシュ ('\') を置けば、継続することができる。 行頭の空白 (white space)は、継続記号を使用している場合でも、 行頭から取り除かれることに注意していただきたい。
BINDPW base64:dGVzdA==
プレーンテキストのパスワードを使用する場合、 パスワードは引用符を付けない単なる文字列にするべきだ。 プレーンテキストのパスワード中には、コメント文字 ('#') があってはならない。また、バックスラッシュ ('\') による特殊文字のエスケープはサポートされていない。
このオプションを使用すると、 LDAP 経由で直接ユーザのネットグループを問い合わせることができる。 そうする方が、sudoRole オブジェクトのうちで '+' という接頭辞を持つ sudoUser を含んでいるものをすべて取得するよりも、 たいていの場合動作が高速になる。LDAP サーバによっては、 nisNetgroup オブジェクトをその nisNetgroupTriple メンバによって検索できるようにするためには、 使用している NIS スキーマに変更を加える必要があるものも存在する。 OpenLDAP の slapd の場合は、 nisNetgroupTriple アトリビュートに以下の変更を加えなければならない。
attributetype ( 1.3.6.1.1.1.1.14 NAME 'nisNetgroupTriple'
DESC 'Netgroup triple'
EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
SUDOERS_DEBUG パラメータは非推奨であり、 将来のリリースでは廃止されることになる。今では同じ情報が、 sudo のデバッグ用フレームワークを通してログに記録されるようになっている。 debug_level の値に 1 や 2 を指定する代わりに、サブシステムとして "ldap" を使用し、重大度 (priority) にそれぞれ diag や info を指定すればよいのだ。 sudo のデバッグを設定する方法について詳細を知りたければ、 sudo.conf(5) のマニュアルをご覧になるとよい (訳注: sudoers(5) のマニュアルの「デバッギング」セクションも参照)。
Netscape 由来のライブラリを使う場合は、 このファイルに認証局の証明書も入れることができる。
Tivoli LDAP ライブラリを使用する場合は、 このファイルに認証局やクライアントの証明書も入れることができる。 また、暗号化することもできる。
TLS_KEYPW base64:dGVzdA==
プレーンテキストのパスワードを使用する場合、 パスワードは引用符を付けない単なる文字列にするべきだ。 プレーンテキストのパスワード中には、コメント文字 ('#') があってはならない。また、バックスラッシュ ('\') による特殊文字のエスケープはサポートされていない。 このオプションを使用するのならば、 /etc/ldap.conf を誰にでも読める状態にしてはいけない。 さもないと、パスワードを公開してしまうことになる。 パスワードの公開を避ける別の方法としては、 stash file を使用することも可能だ。そうすれば、 パスワードを暗号化した形で格納することができる (下記参照)。
TLS_KEYPW が指定されていない場合、 stash file が存在すれば、それを使用することになる。stash file は、 TLS_KEY で指定されるファイルと同じパスを持たなければならないが、 拡張子には .kdb の代わりに、.sth を使わなければならない。 たとえば、ldapkey.sth といった具合だ。 Tivoli ディレクトリ・サーバ出荷時のデフォルトの ldapkey.kdb は、 ssl_password というパスワードを使って暗号化されている。 gsk8capicmd というユーティリティを使用すれば、 キー・データベースの管理と、stash file の作成を行うことができる。 このオプションをサポートしているのは、Tivoli LDAP ライブラリだけである。
「用例」セクションにある ldap.conf のくだりも参照していただきたい。
ビルド時に無効にしないかぎり、sudo はネームサービス・スイッチ・ファイル /etc/nsswitch.conf を調べて、 sudoers セキュリティポリシーの設定を参照する順番を決める。 すなわち、/etc/nsswitch.conf で sudoers: という文字列に始まる行を探し、 その行によって参照順を決定するのである。 気をつけていただきたいのは、sudo は参照中、 マッチする項目に一度出会ったからと言って、そこで参照を終わりにしないことだ。 後でマッチしたものが前にマッチしたものよりも優先されるのである。 以下の参照元が有効である。
なお、[NOTFOUND=return] の記述があると、 先行する参照元にユーザが見つからなかった場合、参照を中断することになる。
最初に LDAP を参照し、その後で (もし存在するならば) ローカルマシン上の sudoers ファイルを調べるには、次のように指定する。
sudoers: ldap files
ローカルマシン上の sudoers ファイルをまったく無視するには、 次のようにする。
sudoers: ldap
/etc/nsswitch.conf ファイルが存在しなかったり、存在しても sudoers の行がなかったりした場合は、次のデフォルト設定が使用される。
sudoers: files
使用しているオペーレーティング・システムが nsswitch.conf ファイルを使用しない場合でも、sudo は、AIX のシステム以外では (次のセクションを参照)、/etc/nsswitch.conf をサポートしていることに注意していただきたい。
AIX システムでは、/etc/nsswitch.conf ではなく、 /etc/netsvc.conf ファイルを調べに行く。sudo としては、 netsvc.conf を nsswitch.conf のバリエーションとして扱うだけだ。 それ故、上のセクションの記述のうち、ファイルの書式に関係のないものは、 ここでも当てはまることになる。
最初に LDAP を参照し、その後で (もし存在するならば) ローカルマシン上の sudoers ファイルを調べるには、次のように指定する。
sudoers = ldap, files
ローカルマシン上の sudoers ファイルをまったく無視するには、 次のようにする。
sudoers = ldap
LDAP を正式の参照元と見なし、LDAP にユーザが見つからなかったときのみ、 ローカルの sudoers ファイルを使用する。
sudoers = ldap = auth, files
注意していただきたいが、上記の例において、auth 修飾子が影響を及ぼすのは、 ユーザを検索するときだけである。 Defaults エントリについては、LDAP と sudoers の両方が参照される。
/etc/netsvc.conf ファイルが存在しなかったり、存在しても sudoers の行がなかったりした場合は、次のデフォルト設定が使用される。
sudoers = files
System Security Services Daemon (SSSD) を使用しているシステムで、 sudo が SSSD サポートを有効にしてビルドされている場合は、 LDAP の sudoers ルールをキャッシュするのに SSSD を使用することができる。 sudoers の参照先として SSSD を使用するためには、 /etc/nsswitch.conf の sudoers のエントリで ldap の代わりに sssd を使わねばならない。なお、SSSD 用の sudo のバックエンドは、 /etc/ldap.conf ファイルを使用しないことに気をつけていただきたい。 SSSD と共に使用するときの sudo の設定についてより詳しい情報をお知りになりたかったら、 sssd-sudo(5) をご覧になるとよい。
# URI または host:port の組み合わせを一つ以上指定する。 # どちらも指定されていない場合、sudo はデフォルトの localhost と # 389 番ポートを使用する。 # #host ldapserver #host ldapserver1 ldapserver2:390 # # host がポートなしで指定されている場合のポート番号。 # デフォルトは 389 である。 #port 389 # # URI による指定は、host と port による指定に優先する。 uri ldap://ldapserver #uri ldaps://secureldapserver #uri ldaps://secureldapserver ldap://ldapserver # # LDAP サーバに接続しようとしているときの、秒単位の待ち時間。 bind_timelimit 30 # # LDAP に問い合わせを行っているときの、秒単位の待ち時間。 timelimit 30 # # 必ず設定すること。さもないと、sudo は LDAP を無視することになる。 # 複数回指定してもよい。 sudoers_base ou=SUDOers,dc=example,dc=com # # LDAP で sudoers セキュリティポリシー設定を問い合わせる際の # マッチングについて詳細情報を表示する。 #sudoers_debug 2 # # sudoers セキュリティポリシー設定中で日時制限のあるエントリの # サポートを有効にする。 #sudoers_timed yes # # LDAP の操作を行う者の認証情報 (設定する、しないは任意)。 #binddn <who to search as> #bindpw <password> #rootbinddn <who to search as, uses /etc/ldap.secret for bindpw> # # LDAP プロトコルのバージョン。デフォルトは 3 である。 #ldap_version 3 # # LDAP 接続を暗号化したい場合に設定する。 # 通例、ポートを 636 (ldaps) にすることも必要。 #ssl on # # ポート 389 を使用し、バインド操作のために認証情報が # 送信される直前に、暗号化セッションに切り替えたい場合に設定する。 # これをサポートしているのは、OpenLDAP のような start_tls 拡張に # 対応している LDAP サーバだけである。 #ssl start_tls # # さらに以下の TLS 関連オプションを使うことで SSL/TLS 接続の # 細かい調整ができる。 # #tls_checkpeer yes # サーバの SSL 証明書の正当性をチェックする。 #tls_checkpeer no # サーバの SSL 証明書の正当性をチェックしない。 # # tls_checkpeer を有効にするときは、 tls_cacertfile か # tls_cacertdir のどちらかを指定すること。tls_cacertfile や # tls_cacertdir は OpenLDAP の使用時のみ使える。 # #tls_cacertfile /etc/certs/trusted_signers.pem #tls_cacertdir /etc/certs # # /dev/random がないシステムでは、下記の設定を PRNGD、あるいは # EGD.pl と一緒に使用すれば、暗号セッション用の鍵を生成するための # 乱数プールの種を供給できる。このオプションが使えるのは、 # OpenLDAP を使用しているときだけである。 # #tls_randfile /etc/egd-pool # # 使用する暗号を限定することができる。どの暗号が使えるかに # ついては、SSL の文書を参照すること。このオプションが # 使えるのは、OpenLDAP を使用しているときだけである。 # #tls_ciphers <cipher-list> # # sudo は LDAP サーバと交信するときに、クライアントの証明書を # 提示することができる。 # 注意: # * 両方の行を同時に有効にすること。 # * キーファイルをパスワードでプロテクトしてはいけない。 # * キーファイルが読めるのは root だけにするのを忘れずに。 # # OpenLDAP の場合: #tls_cert /etc/certs/client_cert.pem #tls_key /etc/certs/client_key.pem # # SunONE や iPlanet LDAP (訳注: Netscape 由来) の場合: # こちらの場合は、tls_cert や tls_key で指定するのは、証明書や # キーファイルの入っているディレクトリでもよく、ファイルそのものの # パスでもよい。前者の場合、ディレクトリ中のファイルは、所定の名前 # (たとえばcert8.db と key4.db) でなければならない。もっとも、 # ファイルのパスを指定した場合は、バージョン 5.0 の LDAP SDK には # バグがあるので、ファイル名によってはうまく動作しないことがある。 # この理由から、tls_cert や tls_key には、ファイル名ではなく、 # ディレクトリを指定する方をお薦めする。 # # tls_cert で指定した証明書のデータベースには、認証局の証明書と # クライアントの証明書が、どちらか一方だけ入っていてもよく、 # 両方入っていてもよい。クライアントの証明書が入っている場合は、 # tls_key も指定するべきである。 # 後方互換のため、tls_cert のかわりに sslpath を使うこともできる。 #tls_cert /var/ldap #tls_key /var/ldap # # LDAP に SASL 認証を使用する場合 (OpenSSL) # use_sasl yes # sasl_auth_id <SASL user name> # rootuse_sasl yes # rootsasl_auth_id <SASL user name for root access> # sasl_secprops none # krb5_ccname /etc/.ldapcache
下記のスキーマは OpenLDAP 用の形式になっており、 sudo のソースやバイナリの配布には schema.OpenLDAP として収録されている。その schema.OpenLDAP ファイルをスキーマ・ディレクトリ (たとえば /etc/openldap/schema) にそのままコピーし、適切な include 行を slapd.conf に追加して、 slapd をリスタートすればよい。
attributetype ( 1.3.6.1.4.1.15953.9.1.1
NAME 'sudoUser'
DESC 'User(s) who may run sudo'
EQUALITY caseExactIA5Match
SUBSTR caseExactIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) attributetype ( 1.3.6.1.4.1.15953.9.1.2
NAME 'sudoHost'
DESC 'Host(s) who may run sudo'
EQUALITY caseExactIA5Match
SUBSTR caseExactIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) attributetype ( 1.3.6.1.4.1.15953.9.1.3
NAME 'sudoCommand'
DESC 'Command(s) to be executed by sudo'
EQUALITY caseExactIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) attributetype ( 1.3.6.1.4.1.15953.9.1.4
NAME 'sudoRunAs'
DESC 'User(s) impersonated by sudo'
EQUALITY caseExactIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) attributetype ( 1.3.6.1.4.1.15953.9.1.5
NAME 'sudoOption'
DESC 'Options(s) followed by sudo'
EQUALITY caseExactIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) attributetype ( 1.3.6.1.4.1.15953.9.1.6
NAME 'sudoRunAsUser'
DESC 'User(s) impersonated by sudo'
EQUALITY caseExactIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) attributetype ( 1.3.6.1.4.1.15953.9.1.7
NAME 'sudoRunAsGroup'
DESC 'Group(s) impersonated by sudo'
EQUALITY caseExactIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) attributetype ( 1.3.6.1.4.1.15953.9.1.8
NAME 'sudoNotBefore'
DESC 'Start of time interval for which the entry is valid'
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) attributetype ( 1.3.6.1.4.1.15953.9.1.9
NAME 'sudoNotAfter'
DESC 'End of time interval for which the entry is valid'
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) attributeTypes ( 1.3.6.1.4.1.15953.9.1.10
NAME 'sudoOrder'
DESC 'an integer to order the sudoRole entries'
EQUALITY integerMatch
ORDERING integerOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) objectclass ( 1.3.6.1.4.1.15953.9.2.1 NAME 'sudoRole' SUP top STRUCTURAL
DESC 'Sudoer Entries'
MUST ( cn )
MAY ( sudoUser $ sudoHost $ sudoCommand $ sudoRunAs $ sudoRunAsUser $ sudoRunAsGroup $ sudoOption $ sudoNotBefore $ sudoNotAfter $ sudoOrder $ description )
)
多数の人々が長年に渡って sudo の開発に携わってきた。 当バージョンは主として次の者が書いたコードからできている。
sudo の開発に貢献してくださった方々の詳細なリストについては、 配布物中の CONTRIBUTORS ファイルをご覧になっていただきたい。 (https://www.sudo.ws/contributors.html)
LDAP を使用する sudoers セキュリティポリシーの設定と sudoers ファイルによる設定では、設定を解析する仕方に相違があるので、 注意していただきたい。詳細については、「LDAP を使う場合と使わない場合の sudoers セキュリティポリシー設定の相違点」のセクションを参照すること。
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
| June 15, 2016 | Sudo 1.8.17 |