SUDOERS.LDAP(5) | MAINTENANCE COMMANDS | SUDOERS.LDAP(5) |
名前¶
sudoers.ldap - LDAP を使った sudo の設定
説明¶
sudo は sudoers ファイルによって設定するのが標準だが、 LDAP を通して設定することも可能だ。この方法は、 大規模な分散環境で sudo の設定を同期させたい場合に、とりわけ便利かもしれない。
sudo の設定に LDAP を使用すると、有利な点がいくつかある。
- sudo はもはや sudo の設定をまるまる全部読み込む必要がない。 LDAP を使用する場合は、sudo の実行ごとに、たった二、三回 LDAP に問い合わせを行うだけですむ。 そのため、LDAP 環境は実行速度が非常に早く、たいへん使い勝手がよい。
- sudo の設定にタイプミスがあっても、もうそのために sudo が終了してしまうことがない。LDAP のデータは、 sudo 用のスキーマに従っていなければ、サーバーにロードできない。 結果として、正しいシンタクスが保証されるわけだ。 ユーザ名やホスト名をタイプミスすることなら相変わらずあるだろうが、 そのために sudo が動かなくなることはない。
- エントリごとにオプションを指定して、 グローバルなデフォルト・オプションを上書きすることができる。 /etc/sudoers はグローバルなデフォルト・オプションと、ユーザ、ホスト、 コマンド、変身対象に結びついた限定されたオプションしかサポートしていない。 また、/etc/sudoers の書式は複雑で、ユーザには理解しにくいかもしれない。 オプションをエントリ内で直接指定する方が、ずっと自然である。
- visudo プログラムはもう必要がない。visudo の役割は /etc/sudoers ファイルのロッキングとシンタクス・チェックである。 LDAP のデータ更新はアトミック操作なので、 (訳注: それ故、データは更新されていないか、 すでに更新されたかのどちらかであって、中間状態がないので)、 ロッキングはもはや必要がない。シンタクスは、 データが LDAP にインサートされるときチェックされるから、 シンタクス・チェック用の特別なツールも不要になっている。
LDAP による設定と sudoers ファイルによる設定との、 もう一つの大きな違いは、LDAP では sudo 専用のエイリアスがサポートされていないことである。
たいていの場合、sudo 専用のエイリアスは実のところ必要がない。 User_Aliases や Runas_Aliases の代わりに、 Unix のグループやユーザのネットグループが使用できる。 また、Host_Aliases の代わりには、ホストのネットグループが使える。 LDAP には Unix のグループやネットグループも格納できるので、 sudo 専用のエイリアスがどうしても必要というわけではないのだ。
Cmnd_Aliases もまったく必要がない。一つの sudoRole エントリに複数のユーザを登録できるからだ。複数のユーザが参照する Cmnd_Alias を定義する代わりに、複数のコマンドを含む sudoRole エントリを一つ作成して、そこに複数のユーザを割り当てればよい。
- [訳注]:
- 原文の著者は、sudo 設定の単位となる objectClass 属性が sudoRole の LDAP エントリのうち、/etc/sudoers の各ユーザ設定に相当するものを「a sudoRole」と呼んでいる。 「sudoRole エントリ」という訳語を当てた。
LDAP の SUDOers コンテナ¶
LDAP では、sudo の設定は ou=SUDOers コンテナの下に配置されている。
- [訳注]:
- コンテナとは、データを格納するためにではなく、 下位のエントリをまとめておくために存在する上位エントリを言う。たとえば、 OpenLDAP 用の ou=SUDOers コンテナなら、こんなふうになる (sudo 同梱の README.LDAP から引用)。
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 エントリである。それは以下の属性からなっている。
- sudoUser
- 次のうちのいづれか。ユーザ名、 ユーザ ID (接頭辞 '#' が付く)、 Unix グループ名 (接頭辞 '%' が付く)、 Unix グループ ID (接頭辞 '%#' が付く。これが使えるのは、sudo-1.8.4 から)、 ユーザのネットグループ名 (接頭辞 '+' が付く)。
- sudoHost
- 次のうちのいづれか。ホスト名、IP アドレス、ネットワークアドレス、 ホストのネットグループ名 (接頭辞 '+' が付く)。 ALL という特別な値はいかなるホストにもマッチする。
- sudoCommand
- Unix のコマンド。コマンドライン引数を付けてもよく、glob 文字 (ワイルドカードとも言う) を含んでいてもよい。ALL という特別な値は、いかなるコマンドにもマッチする。 コマンドに感嘆符 '!' を接頭辞として付けると、 ユーザにそのコマンドの実行を禁じることになる。
- sudoOption
- 働きは、前述のグローバルオプションと同じだが、それが属している sudoRole エントリに対してのみ効果がある。
- sudoRunAsUser
- 変身対象となるユーザ名か
uid (接頭辞 '#'
が付く) を指定する。
変身対象ユーザをリストに含む
Unix グループ名 (接頭辞
'%' が付く) や、
ユーザのネットグループ名
(接頭辞 '+'
が付く) も使える。
特別な値 ALL
は、いかなるユーザにもマッチする。
属性 sudoRunAsUser は、 バージョン 1.7.0 以上の sudo でなければ、利用できない。 それ以前のバージョンの sudo では、 代わりに属性 sudoRunAs を使用している。
- sudoRunAsGroup
- 変身対象となる Unix
グループ名か gid
(接頭辞 '#'
が付く)。 特別な値
ALL
はいかなるグループにもマッチする。
属性 sudoRunAsGroup は、 バージョン 1.7.0 以上の sudo でなければ、利用できない。
- sudoNotBefore
- yyyymmddHHMMSSZ
形式のタイムスタンプ。
この属性を含む
sudoRole
エントリがいつから有効になるかという、
スタート日時を指定するのに使用する。
複数の sudoNotBefore
が存在する場合は、
一番早い日時が採用される。
タイムスタンプは協定世界時
(UTC)
によるものでなければならず、
ローカル・タイムゾーンによるものではないことに注意してほしい。
分や秒の部分は省略できるが、LDAP
サーバによっては (RFC
の規定とは逆に)
分や秒の指定を必須にしていることもある。
属性 sudoNotBefore は、 バージョン 1.7.5 以上の sudo でなければ、利用できない。 また、/etc/ldap.conf の SUDOERS_TIMED オプションで明示的に有効にする必要がある。
- sudoNotAfter
- yyyymmddHHMMSSZ
形式のタイムスタンプ。
この属性を含む
sudoRole
エントリがもはや有効ではなくなる、
失効日時を示している。
複数の sudoNotAfter
が存在する場合は、
一番最後の日時が採用される。
タイムスタンプは協定世界時
(UTC)
によるものでなければならず、
ローカル・タイムゾーンによるものではないことに注意してほしい。
分や秒の部分は省略できるが、LDAP
サーバによっては (RFC
の規定とは逆に)
分や秒の指定を必須にしていることもある。
属性 sudoNotAfter は、 バージョン 1.7.5 以上の sudo でなければ、利用できない。 また、/etc/ldap.conf の SUDOERS_TIMED オプションで明示的に有効にする必要がある。
- sudoOrder
- LDAP から取り出される
sudoRole
エントリには、
固有の順番というものがない。
そこで、整数の値を取る
sudoOrder
属性を使用して
(浮動小数点値をサポートする
LDAP
サーバでは、浮動小数点値が使える)、
マッチするエントリの順番付けを行う。
そうすることによって、LDAP
による sudo
設定のエントリが、
sudoers
ファイルの動作をより忠実に真似られるようになるのだ。
sudoers
ファイルではエントリの順番が結果に影響を及ぼす。
sudoOrder
属性を使用すると、
複数のエントリがマッチする場合は、一番大きな
sudoOrder
属性を持つエントリが選ばれることになる。この動作は、
sudoers
ファイルの「最後にマッチしたものが選ばれる」動作に相当するわけだ。
sudoOrder
属性が指定されていない場合は、
値が 0
であると見なされる。
属性 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 を使って sudo の設定を検索するときの詳細¶
LDAP を使ってユーザの sudo 設定を検索するとき、LDAP の問い合わせは sudo の実行ごとにたった二回か三回行われるだけである。一回目の問い合わせは、 グローバル・オプションを解析するために行われる。二回目の問い合わせは、 sudo を実行するユーザのユーザ名や、 所属グループに対応するエントリを見つけるためだ (特別なタグ ALL が何にでもマッチするのは、この場合も同様である)。 ユーザ名やグループに対応するエントリが得られなかった場合は、 三回目の問い合わせが行われ、 ユーザのネットグループを含んでいるすべてのエントリーを取得して、 問題のユーザがそのどれかに属していないかチェックする。
/etc/ldap.conf の設定オプション SUDOERS_TIMED を有功にして、 日時制限があるエントリを使えるようにしている場合は、 LDAP の問い合わせにサブフィルターによる選別が伴うことになる。 そのサブフィルターが、日時制限が存在するエントリについては、 その制限を満たしているエントリのみに、情報の取り出しを限定するのである。
LDAP を使う場合と使わない場合の sudo 設定の相違点¶
LDAP を使用する場合、sudo の設定の処理方法に /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 用のスキーマ¶
sudo の LDAP サポートを利用するためには、 お使いの LDAP サーバに sudo 用のスキーマをインストールしなければならない。 さらに、'sudoUser' 属性の索引も必ず作成する。
たぶん、sudo の配布物中に三種類のスキーマが入っていると思う。 すなわち OpenLDAP サーバ用 (schema.OpenLDAP)、 Netscape ディレクトリサーバの流れを汲むサーバ用 (schema.iPlanet)、 Microsoft Active Directory 用 (schema.ActiveDirectory) のスキーマである。
OpenLDAP 用の形式にした sudo のスキーマは、 「用例」セクションにも記載しておいた。
ldap.conf の設定¶
sudo は LDAP に関する設定を知るために /etc/ldap.conf を読み込む。 通例、このファイルは、 LDAP に対応しているさまざまなクライアントの間で共有されている。 それ故、設定の大部分は sudo 専用ではない。 注意すべきは、sudo は /etc/ldap.conf を独自に解析しており、 ldap.conf(5) のマニュアルで説明されているものとは 異なるオプションをサポートしていることがあるということだ。
もうひとつ注意してほしいのは、OpenLDAP ライブラリを使っているシステムで、 /etc/openldap/ldap.conf やユーザの .ldaprc ファイルで指定しているデフォルト値が使用されないことである。
すなわち、/etc/ldap.conf に明示的に記載され、かつ sudo でサポートされているオプションのみが使用される。 設定オプションを以下に大文字で列挙するが、 解析されるときは大文字小文字は区別されない。
- URI ldap[s]://[hostname[:port]] ...
- 接続する一個以上の LDAP サーバ の URI を、空白 (whitespace) で区切ったリストの形で指定する。プロトコルは ldap と ldaps のどちらでもよい。 後者は TLS (SSL) 暗号化に対応しているサーバの場合である。 ポートを指定しないときのデフォルトは、 ldap:// では 389 番ポート、 ldaps:// では 636 番ポートである。 hostname を一つも指定しないと、 sudo は localhost に接続することになる。 URI の行が二行以上ある場合は、 URI の行に複数のエントリがあるときと同様に処理される。 OpenSSL ライブラリを使用しているシステムのみが、ldap:// と ldaps:// 両方の URI を混ぜて使うことに対応している。 たいていの商用 Unix では Netscape 由来のライブラリが使用されているが、 そうしたライブラリはどちらか一方に対応することしかできない。
- HOST name[:port] ...
- URI パラメータが指定されていない場合は、 HOST パラメータで指定する空白 (whitespace) で区切ったリストが、接続する LDAP サーバである。 各ホストにはコロン (':') に続けて、ポート番号を書いてもよい。 HOST パラメータは非推奨であり、URI で指定する方が望ましい。このパラメータがあるのは、後方互換のためである。
- PORT port_number
- URI パラメータが指定されず、HOST パラメータでもポートが指定されていないときは、PORT パラメータが LDAP サーバに接続するときのデフォルトのポートを指定する。 PORT パラメータが使用されていない場合、デフォルトのポートは LDAP では 389 番、LDAP over TLS (SSL) では 636 番である。PORT パラメータは非推奨であり、 URI で指定する方が望ましい。 このパラメータがあるのは、後方互換のためである。
- BIND_TIMELIMIT seconds
- 接続しようとするときの待ち時間を秒数で指定する。URI や HOST が複数指定されている場合は、その時間だけ待ってから、 リスト中の次のサーバに接続を試みることを意味する。
- NETWORK_TIMEOUT seconds
- BIND_TIMELIMIT の別名。OpenLDAP との互換のためにある。
- TIMELIMIT seconds
- TIMELIMIT パラメータは、 LDAP 参照に対して応答が返ってくるまでの待ち時間を秒数で指定する。
- TIMEOUT seconds
- TIMEOUT パラメータは、 様々な LDAP API から応答が返ってくるときの待ち時間を秒数で指定する。
- SUDOERS_BASE base
- sudo が LDAP 参照を行うときに使用するベース DN を指定する。ドメインが example.com ならば、 普通 ou=SUDOers,dc=example,dc=com という形になる。 SUDOERS_BASE を複数回指定してもよい。その場合は、 指定された順番で参照されることになる。
- SUDOERS_SEARCH_FILTER ldap_filter
- sudo が LDAP 参照を行うとき、どんな情報を返すかを限定する LDAP のフィルター。 普通これは、attribute=value とか (&(attribute=value)(attribute2=value2)) という形を取る。
- SUDOERS_TIMED on/true/yes/off/false/no
- 属性 sudoNotBefore や sudoNotAfter を評価するか、しないかを指定する。 この二つの属性によって日時制限のある sudo 設定のエントリを実現している。
- SUDOERS_DEBUG debug_level
- sudo が LDAP 参照をするときのデバッグレベルを決める。 デバック情報の出力先は標準エラーである。値を 1 にすると、 多からず少なからずほどほどのデバック情報が表示される。 値を 2 にすると、マッチの結果そのものも出力される。 実用環境では、このパラメータを設定するべきではない。 ユーザが余計な情報に混乱しかねないからだ。
- BINDDN DN
- BINDDN パラメータは、誰の名前で LDAP の操作を行うかを、 識別名 (DN) を使って指定する。これが指定されていない場合、 LDAP の操作は anonymous の名前で実行される。LDAP サーバは、 たいていデフォルトで anonymous によるアクセスを許可しているものである。
- BINDPW secret
- BINDPW パラメータは、 LDAP の操作を行うときに使用するパスワードを指定する。 通例、このパラメータは、BINDDN パラメータと組み合わせて使用する。
- ROOTBINDDN DN
- ROOTBINDDN パラメータは、sudo 設定の参照のような、 特権的な LDAP 操作をするとき、誰の名前で行うかを識別名 (DN) を使って指定する。その名前に対応するパスワードは /etc/ldap.secret に書き込んでおくべきだ。このパラメータが設定されていない場合は、 BINDDN で指定した名前があるならば、それが使用される。
- LDAP_VERSION number
- サーバに接続するときに使用する LDAP プロトコルのバージョン。 デフォルトの値は、プロトコルバージョン 3 である。
- SSL on/true/yes/off/false/no
- SSL パラメータが on, true, yes になっていると、LDAP サーバと通信する際に、常に TLS (SSL) の暗号化を使用することになる。 通例、それは 636 番ポート (ldaps) を通してサーバに接続することである。
- SSL start_tls
- SSL パラメータを start_tls に設定すると、 LDAP サーバへの接続を平文で開始し、 バインド操作のために認証情報を送信する直前に、 TLS の暗号化を始めることになる。 これには、暗号化された通信のために専用のポートを必要としないという長所がある。 このパラメータをサポートしているのは、 OpenLDAP サーバのような start_tls 拡張に対応している LDAP サーバのみである。
- TLS_CHECKPEER on/true/yes/off/false/no
- TLS_CHECKPEER が有効になっていると、 LDAP サーバの TLS 証明書が正当かどうかチェックが行われる。 LDAP サーバの証明書が正当であることを確認できない場合 (たいていは、 署名している認証局が未知 (unknown) であることが理由だ)、 sudo はそのサーバに接続することができない。 TLS_CHECKPEER が無効になっている場合は、チェックが行われない。 気をつけてほしいが、このチェックをやらないことにすると、 サーバーの身元確認を行わないので、中間者攻撃の可能性が生じる。 可能ならば、認証局の証明書は、その正当性をチェックできるように、 手元のマシンにインストールしておくべきである。
- TLS_CACERT file name
- TLS_CACERTFILE の別名。OpenLDAP との互換のためにある。
- TLS_CACERTFILE file name
- 認証局の証明書を一つにまとめたファイルのパス。たとえば、 /etc/ssl/ca-bundle.pem といったファイルであり、 正当なものだとクライアントが認識している、すべての認証局の証明書がそこに入っている。 このオプションをサポートしているのは、OpenLDAP ライブラリだけである。 Netscape 由来の LDAP ライブラリは、認証局とクライアント、 両方の証明書に対して、同一の証明書データベースを使用する (TLS_CERT を参照)。
- TLS_CACERTDIR directory
- TLS_CACERTFILE に似ているが、ファイルではなく、たとえば /etc/ssl/certs といったディレクトリであり、認証局の証明書が 1 認証局 1 ファイルの形でそこに入っている。TLS_CACERTDIR で指定したディレクトリは、TLS_CACERTFILE の後でチェックされる。 このオプションをサポートしているのは、OpenLDAP ライブラリだけである。
- TLS_CERT file name
- クライアントの証明書が入っているファイルのパス。この証明書は、
LDAP
サーバに対するクライアントの認証に使用できる。
証明書のタイプは、利用する
LDAP
ライブラリによって異なっている。
OpenLDAP:
tls_cert /etc/ssl/client_cert.pemNetscape 由来:
tls_cert /var/ldap/cert7.dbNetscape 由来のライブラリを使う場合は、このファイルに認証局の証明書も入れることができる。
- TLS_KEY file name
- TLS_CERT
で指定した証明書に対応する、
秘密鍵が入っているファイルのパス。
この秘密鍵はパスワードでプロテクトされていてはならない。
鍵のタイプは利用する
LDAP
ライブラリによって異なっている。
OpenLDAP:
tls_key /etc/ssl/client_key.pem
tls_key /var/ldap/key3.db - TLS_RANDFILE file name
- TLS_RANDFILE は、random デバイスを持っていないシステムのために エントロピー・ソースのパスを指定する。 これは通例、prngd や egd と組み合わせて使用するものである。 このオプションをサポートしているのは、OpenLDAP ライブラリだけである。
- TLS_CIPHERS cipher list
- 管理者は TLS_CIPHERS パラメータによって、TLS (SSL) 接続に使用可能な暗号アルゴリズムを限定することができる。 有効な暗号のリストについては OpenSSL のマニュアルを参照してほしい。 このオプションをサポートしているのは、OpenLDAP ライブラリだけである。
- USE_SASL on/true/yes/off/false/no
- LDAP サーバが SASL 認証をサポートしているなら、 USE_SASL を有効にすること。
- SASL_AUTH_ID identity
- LDAP サーバに接続するときに使用する SASL ユーザ名。 デフォルトでは、sudo は anonymous 接続を使用する。
- ROOTUSE_SASL on/true/yes/off/false/no
- ROOTUSE_SASL を有効にすると、 sudo のような特権的なプロセスから LDAP サーバに接続するときに SASL 認証が可能になる。
- ROOTSASL_AUTH_ID identity
- ROOTUSE_SASL が有効なとき使用する SASL ユーザ名。
- SASL_SECPROPS none/properties
- SASL セキュリティ・プロパティを指定する。プロパティなしならば、 none である。 詳細については、SASL プログラマーズ・マニュアルを参照すること。
- KRB5_CCNAME file name
- リモート・サーバに対して認証をするときに使用する Kerberos 5 資格証明キャッシュのパス。
- DEREF never/searching/finding/always
- 検索を行うときに、alias の参照をどうするかを指定する。 このオプションについての詳しい説明は、ldap.conf(5) のマニュアルにある。
「用例」セクションにある ldap.conf のくだりも参照してほしい。
nsswitch.conf の設定¶
ビルド時に無効にしないかぎり、sudo はネームサービス・スイッチ・ファイル /etc/nsswitch.conf を調べて、sudo の設定を参照する順番を決める。 すなわち、/etc/nsswitch.conf で sudoers: という文字列に始まる行を探し、 その行によって参照順を決定するのである。 気をつけてほしいのは、sudo は参照中、 マッチする項目に一度出会ったからと言って、そこで参照を終わりにしないことだ。 後でマッチしたものが前にマッチしたものよりも優先されるのである。
以下の参照元が有効である。
files /etc/sudoers から sudo の設定を読み込む ldap LDAP から sudo の設定を読み込む
なお、[NOTFOUND=return] の記述があると、 先行する参照元にユーザが見つからなかった場合、参照を中断することになる。
最初に LDAP を参照し、その後で (もし存在するならば) ローカルマシン上の sudoers ファイルを調べるには、次のように指定する。
sudoers: ldap files
ローカルマシン上の sudoers ファイルをまったく無視するには、 次のようにする。
sudoers: ldap
/etc/nsswitch.conf ファイルが存在しなかったり、存在しても sudoers の行がなかったりした場合は、次のデフォルト設定が使用される。
sudoers: files
基盤となるオペーレーティング・システムが nsswitch.conf ファイルを使用しない場合でも、sudo は /etc/nsswitch.conf をサポートしていることに注意してほしい。
netsvc.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
ファイル¶
- /etc/ldap.conf
- LDAP の設定ファイル
- /etc/nsswitch.conf
- sudo の設定の参照元の順番を決める
- /etc/netsvc.conf
- AIX で sudo の設定の参照元の順番を決める
用例¶
ldap.conf の一例¶
# 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 を参照したとき、sudo 設定のマッチングについて詳細情報を # 表示する。 #sudoers_debug 2 # # sudo 設定中で日時制限のあるエントリのサポートを有効にする。 #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 接続を暗号化したいなら、on にする。 # 通例、ポートを 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 の場合: # こちらの場合は、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 のスキーマ¶
下記のスキーマは OpenLDAP 用の形式になっており、 sudo のソースやバイナリの配布に含まれる 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 ) )
関連項目¶
警告¶
LDAP を使用する sudo の設定と sudoers ファイルによる sudo の設定では、 設定を解析する仕方に相違があるので、注意してほしい。詳細については、 「LDAP を使う場合と使わない場合の sudo 設定の相違点」のセクションを参照すること。
バグ¶
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
January 6, 2012 | 1.8.4 |