長南洋一
cyoic****@maple*****
2016年 9月 7日 (水) 09:41:15 JST
Fork長南です。
さすがに sudoers については、長くなりました。
以下に問題点を書き出しましたが、書き出した順番は man 中で出てくる順番と
同じではありません。かなり前後しています。本文中の位置を突き止めるのが
大変になり、恐縮です。
○ 「コマンド環境 (Command environment)」セクションの、
値が () で始まる変数の話ですが、こんな理解でよいのでしょうか。
原文が説明不足だと思ったので、一応、shellshock 問題以前の
古い bash (debian squeeze の bash-4.1.5) で動作を確かめて、
訳注を付けましたが、正しいかどうか自信がありません。
By default, environment variables are matched by name. However, if the
pattern includes an equal sign (‘=’), both the variables name and value
must match. For example, an old-style (pre-shellshock) bash shell
function could be matched as follows:
env_keep += "my_func=()*"
Without the =()* suffix, this would not match, as old-style bash shell
functions are not preserved by default.
デフォルトでは、環境変数のマッチは変数名によって行われる。 しかしなが
ら、マッチに使われるパターンに等号 ('=') が含まれる場合は、 変数名と値
の両方がマッチしなければならない。たとえば、旧式の (shellshock 問題以前
の export 方法による) bash のシェル関数にマッチさせるならば、次のように
指定すればよいだろう。
env_keep += "my_func=()*"
旧式の bash のシェル関数は、デフォルトでは保存されないので、 "=()*" と
いう後続部分がなかったら、こうした環境変数はマッチしないことになる。
[訳注]: shellshock 以前の bash では、たとえば "my_func='() { ls -F; }'"
といったシェル変数を export することで、 my_func という関数をサ
ブシェルに渡すことができた。 shellshock 以後の bash では、この
方法による関数の継承はできなくなり、 値が "() { ls -F; }" であ
る my_func という変数が、 渡されるだけになっている。だから、
sudoers ファイルの Defaults 行に上のように書いても、 shellshock
以後の bash を使っているかぎり、 my_func という環境変数が保存さ
れるだけで、関数が渡されるわけではない。
○ 「User_List」などの説明のネットグループに関する部分。
... User netgroups are matched using the user and domain members only;
the host member is not used when matching.
... なお、ユーザのネットグループについては、 ネットグループの
成員中のユーザとドメインの要素のみを使って、マッチングが行われる。
ホストの要素はマッチングに使用されない。
原文の member という用語の使い方が疑問です (確かに、member と言えば、
member に相違ありませんが)。man netgroup などを見ても、普通は、
あるネットグループの構成員を member と言い、その個々の member を
定義する三つ組 "(host, user, domain)" の host や user については、
field とか element とか言うようです。それで、上のように訳しておきました。
○ ついでに、「Host_List」の部分。
... Host netgroups are matched using the host (both qualified and
unqualified) and domain members only; the user member is not used
when matching.
... なお、 ホストのネットグループについては、ネットグループの
成員中のホスト (完全修飾名とそうでないもののどちらでも) と
ドメインの要素のみを使って、マッチングが行われる。ユーザの要素は
マッチングに使用されない。
"(both qualified and unqualified)" の部分が、具体的にどういうことか
わかりません。
○ 「ユーザの認証 (User Authentication)」セクションから。
If sudo is run by root and the SUDO_USER environment variable is set,
the sudoers policy will use this value to determine who the actual user
is. This can be used by a user to log commands through sudo even when
a root shell has been invoked. It also allows the -e option to remain
useful even when invoked via a sudo-run script or program. Note,
however, that the sudoers file lookup is still done for root, not the
user specified by SUDO_USER.
sudo が root によって実行されたとき、環境変数 SUDO_USER が設定されてい
ると、 sudoers ポリシーは、実際のユーザが誰かを判断するのに、その値を使
用することになる。 ユーザとしては、この動作を利用することで、すでにルー
トシェルを起動している場合でも、 自分が sudo を介して実行したコマンドの
ログを取ることができる。 また、この動作のおかげで、sudo で実行するスク
リプトやプログラムから呼び出される場合でさえ、 -e オプションが役に立つ
ものになっている。ただし、そうした場合でも、 sudoers ファイルの参照はや
はり root に対してなされるのであって、 SUDO_USER が指定しているユーザに
対してではないことに注意していただきたい。
「すでにルートシェルを起動している場合でも、 自分が sudo を介して
実行したコマンドのログを取ることができる」というのは、I/O ログの
ことだと思います。それはいいのですが、その後の "It also allows
the -e option to remain useful even when invoked via a
sudo-run script or program." の部分が、具体的には何を言っているのか
よくわかりません。
○ 新しく使えるようになった sudoers のオプション (フラグ)、
exec_background の訳に自信がありません。とくに、"The advantage of
initially running the command in the background is" 前後の論理的な
つながりが、よくわかりません。
exec_background By default, sudo runs a command as the foreground
process as long as sudo itself is running in the
foreground. When the exec_background flag is enabled
and the command is being run in a pty (due to I/O
logging or the use_pty flag), the command will be run
as a background process. Attempts to read from the
controlling terminal (or to change terminal settings)
will result in the command being suspended with the
SIGTTIN signal (or SIGTTOU in the case of terminal
settings). If this happens when sudo is a foreground
process, the command will be granted the controlling
terminal and resumed in the foreground with no user
intervention required. The advantage of initially
running the command in the background is that sudo
need not read from the terminal unless the command
explicitly requests it. Otherwise, any terminal
input must be passed to the command, whether it has
required it or not (the kernel buffers terminals so
it is not possible to tell whether the command really
wants the input). This is different from historic
sudo behavior or when the command is not being run in
a pty.
exec_background デフォルトでは、sudo 自体がフォアグラウンドで実行され
ているかぎり、 コマンドは sudo によってフォアグラウン
ド・プロセスとして実行される。それに対して、
exec_background フラグが有効になっている場合は、 コマ
ンドが (入出力ロギングや use_pty フラグのために) pty
で実行されていると、 そのコマンドはバックグラウンド・
プロセスとして実行されることになる。 このとき、そのコ
マンドが制御ターミナルから読み込みを行おうとすると
(あるいは、ターミナルの設定を変更しようとすると）、
コマンドは SIGTTIN シグナル (ターミナル設定の場合は
SIGTTOU シグナル) によってサスペンドされる。そうした
ことが起きても、 sudo がフォアグラウンド・プロセスな
らば、 そのコマンドは制御ターミナルの使用を許可され、
ユーザが何の操作をしないでも、フォアグラウンドで実行
が再開される。 コマンドの実行をバックグラウンドで始め
ることの利点は、 そうすれば、コマンドが明示的に要求し
ないかぎり、 sudo はターミナルから読み込みを行う必要
がないということである。 そうしない場合は、コマンドが
入力を要求しているか否かに関わりなく、 いかなる入力も
コマンドに渡さなければならないのだ (カーネルがターミ
ナルのバッファリングをしているので、 コマンドが本当に
その入力を必要としているかどうかを、 判断することはで
きないのである)。 この動作は、従来の sudo の動作とは
異なっている。 また、コマンドが pty で実行されていな
いときの動作とも異なっている。
○ 前々から気になっていたのですが、ignore_local_sudoers の Enterprises は
「企業」なのでしょうか。それとも、「野心的な (遠大な) 計画」なのでしょうか。
ignore_local_sudoers
If set via LDAP, parsing of /etc/sudoers will be
skipped. This is intended for Enterprises that wish
to prevent the usage of local sudoers files so that
only LDAP is used. This thwarts the efforts of rogue
operators who would attempt to add roles to
/etc/sudoers. (以下略)
ignore_local_sudoers
LDAP の方でこのフラグをセットすると、/etc/sudoers の
解析がスキップされることになる。 このフラグは、ローカ
ルにある sudoers ファイルの使用を禁じて、 LDAP のみを
使うようにしたい諸企業のためにある。 たちの悪いオペ
レータが /etc/sudoers に手を加えて、 自分の権限を増や
そうとしても、そうした悪だくみは阻止されるわけだ。
Enterprises と大文字で、複数で、定冠詞が付いていないのは、
どういうことなんでしょう。「野心的計画」なら、定冠詞が付きそうな
気がするし ...。
ついでに言うと、roles は SELinux の role と関係があるのでしょうか。
○ 「グループ・プロバイダー・プラグイン (GROUP PROVIDER PLUGINS)」
セクションの system_group プラグインの説明は、内容を理解しないで
訳しています。これで大丈夫でしょうか。
system_group
The system_group plugin supports group lookups via the
standard C library functions getgrnam() and getgrid(). This
plugin can be used in instances where the user belongs to
groups not present in the user's supplemental group vector.
This plugin takes no options:
Defaults group_plugin=system_group.so
system_group
system_group プラグインは、標準 C ライブラリの関数 getgrnam()
と getgrid() によるグループ検索をサポートしている。このプラグ
インは、 ユーザがそのユーザの補助グループのリストに存在しない
グループに所属しているといった場合にも使用できる。 このプラグ
インはオプションを取らないので、書式は次のようになる。
Defaults group_plugin=system_group.so
○ 「タイムスタンプ・ファイルのチェック (Time stamp file checks)」
サブセクションの最後の段落の後半の論理が、翻訳ではたどたどしくなって
しまいました。もうちょっとすっきりさせられないかと思っています。
Since time stamp files live in the file system, they can outlive a
user's login session. As a result, a user may be able to login, run a
command with sudo after authenticating, logout, login again, and run
sudo without authenticating so long as the record's time stamp is
within 5 minutes (or whatever value the timeout is set to in the
sudoers file). When the tty_tickets option is enabled, the time stamp
record includes the device number of the terminal the user
authenticated with. This provides per-tty granularity but time stamp
records still may outlive the user's session. The time stamp record
also includes the session ID of the process that last authenticated.
This prevents processes in different terminal sessions from using the
same time stamp record. It also helps reduce the chance that a user
will be able to run sudo without entering a password when logging out
and back in again on the same terminal.
タイムスタンプ・ファイルはファイルシステム中に作られるものだから、 ユー
ザのログイン・セッションが終わっても残っている。 そのため、ユーザがログ
インし、認証を行ってから sudo を使ってコマンドを実行し、一旦ログアウト
して、再度ログインしたとき、 認証なしで sudo を実行することが可能になっ
てしまうかもしれない。 タイムスタンプ・ファイルに記録されているタイムス
タンプが 5 分以内のものであれば (あるいは、sudoers ファイルで設定されて
いるタイムアウト時間以内のものであれば)、 そういうことが可能かもしれな
いのだ。 tty_tickets オプションが有効な場合は、タイムスタンプの記録に、
ユーザが認証するときに使った端末のデバイス番号が含まれる。それよって、
tty ごとの細かい管理が可能になるが、それでもタイムスタンプの記録が、
ユーザのセッションが終わった後まで有効である可能性もある。 また、タイム
スタンプの記録には、最後に認証を行ったプロセスのセッション ID も含まれ
る。 別の端末セッションのプロセスが、同じタイムスタンプの記録を使えない
ようにしているのだ。 それはまた、ユーザがログアウトし、再度同じ端末にロ
グインしたときに、 パスワードを入力することなしに sudo を実行できる可能
性を減少させてもいる。
○ 「デバッギング (DEBUGGING)」セクションに一例としてあげられている Debug 行。
Debug sudo /var/log/sudo_debug match ＠ info,nss ＠ info
これは、sudo-1.8.17 では、次のように、デバッグ対象にプラグイン名を
明示的に指定する必要がありそうです。
Debug sudoers.so /var/log/sudo_debug match ＠ info,nss ＠ info
--
長南洋一