Akihiro Motoki
amoto****@gmail*****
2016年 9月 5日 (月) 02:30:32 JST
訳についてはあまり見ていないのですが、質問内容を見ると、 原文と実際の挙動の違いに関するものが多いように見えます。 訳の場所で議論するのもいいのですが、upstream で議論した方が建設的なように思いました (バグレポートをする、議論する、修正を出す、などいろいろなアプローチがあると思います)。 個人的な印象では、Upstream に持って行った方が早く結論が出る場面が多いです。 長南さんのように細かい点まで内容をチェックしている人は少ないと思いますので、 喜ばれると思います。 2016年8月27日 11:46 長南洋一 <cyoic****@maple*****>: > 長南です。 > > わからないところがあるのですが、それをどう説明するかが難しい。 > モタモタしているうちに、日にちが経ってしまいました。 > 混乱した説明になると思いますが、とにかく書いてしまいます。 > > 長すぎる引用ですが、次の二ヶ所は、sudo-1.8.4 の man には > 存在しなかった部分です。内容がよくわからないまま訳していますから、 > つじつまの合わないところがあるかもしれません。お気づきの点が > あれば、ご指摘ください。 > > Process model > When sudo runs a command, it calls fork(2), sets up > the execution environment as described above, and calls > the execve system call in the child process. The main sudo > process waits until the command has completed, then > passes the command's exit status to the security > policy's close function and exits. If an I/O logging > plugin is configured or if the security policy explicitly > requests it, a new pseudo-terminal (pty) is created and > a second sudo process is used to relay job control signals > between the user's existing pty and the new pty the command > is being run in. This extra process makes it possible to, > for example, suspend and resume the command. Without it, > the command would be in what POSIX terms an orphaned process group > and it would not receive any job control signals. As a special > case, if the policy plugin does not define a close function and > no pty is required, sudo will execute the command directly > instead of calling fork(2) first. The sudoers policy plugin > will only define a close function when I/O logging is > enabled, a pty is required, or the pam_session or pam_setcred > options are enabled. Note that pam_session and pam_setcred > are enabled by default on systems using PAM. > > プロセス・モデル > sudo は、コマンドを実行するとき、まず fork(2) を呼び、 > 実行環境を上記のように設定してから、子プロセスで execve > システムコールを呼び出す。 メインの sudo プロセスは、 > コマンドが完了するまで wait し、完了したら、 コマンドの > 終了ステータスをセキュリティポリシーの close 関数に渡してから、 > 終了する。入出力ロギング・プラグインが設定されている場合や、 > セキュリティポリシーが明示的にそれを要求している場合は、 > 擬似端末 ("pty") が新規に作成され、二つ目の sudo プロセスが、 > 既に存在しているユーザの pty と、コマンドがそこで実行されて > いる新しい pty との間で、 ジョブ制御シグナルを中継するために > 使用される。この二つ目の sudo プロセスによって、たとえば、 > コマンドのサスペンドやレジュームといったことが可能になるので > ある。 この仕組みがなければ、コマンドは、POSIX で "orphaned > process group" と言われる状態に陥り、どんなジョブ制御シグナル > も受け取れないことになってしまうだろう。 なお、特殊ケースとして > 次のことがある。ポリシー・プラグインが close 関数を定義していず、 > しかも、pty が要求されていない場合は、 sudo は fork(2) を最初に > 呼ぶことをせず、直接コマンドを実行する。sudoers ポリシー・ > プラグインで close 関数が定義されることになるのは、入出力 > ロギングが有効か、pty が要求されているか、pam_session または > pam_setcred が有効な場合だけである。PAM を使用している > システムでは、 デフォルトで pam_session と pam_setcred が > 有効になることに注意していただきたい。 > > 自分で気がついたことですが、「特殊ケースとして (As a special case)」 > 以下の文は、実際の動作とは違うのではないかと思います。 > > うちの debian jessie には /etc/pam.d/sudo がありますから、 > PAM を使用している (と言うことは、プラグインは close 関数を > 定義している) と思いますが、念のため /etc/sudoers に > > Defaults !use_pty > Defaults pam_session > Defaults pam_setcred > > と書いて、sudo-1.8.17 で "sudo sleep 15" を実行してみました。 > "ps axf" で見ると、こうなります。 > > 1240 ? S 0:00 xterm -class UXTerm ... > 1246 pts/0 Ss 0:00 \_ bash > 1817 pts/0 S+ 0:00 \_ sleep 15 > > つまり、実際の動作は、「close 関数が定義されていず、しかも、 > pts が要求されていないと、sudo は fork せず、直接コマンドを > 実行する」ではなく、「close 関数が定義されているか、いないかに > 関係なく、pts が要求されていないならば、直接コマンドを実行する」 > のようです。 > > ちなみに、"Defaults use_pts" の場合の "ps axf" の結果は次の > ようになります (pam_session, pam_setcred を有効にしても、 > 無効にしても、結果は同じ)。 > > 1240 ? S 0:00 xterm -class UXTerm ... > 1246 pts/0 Ss 0:00 \_ bash > 1795 pts/0 S+ 0:00 \_ sudo sleep 15 > 1796 pts/3 Ss 0:00 \_ sudo sleep 15 > 1797 pts/3 S+ 0:00 \_ sleep 15 > > まとめて言うと、「sudo-1.8.17 では、pty が要求されていれば、 > sudo は fork する」。 > > 原文の説明が古くなっているのでしょうか (sudo-1.8.10 あたりから > 記述が変わっていません)。それとも、わたしが何か勘違いをしている > のでしょうか。 > > 今朝、ふと思いついて、jessie のデフォルトの sudo-1.8.10p3 で > "/usr/bin/sudo sleep 15" を試してみました。 > > 条件を次のようにした場合。 > > Defaults !use_pty > Defaults pam_session > Defaults pam_setcred > > "ps axf" は、 > > 1240 ? S 0:00 xterm -class UXTerm -title ... > 1246 pts/0 Ss 0:00 \_ bash > 1597 pts/0 S+ 0:00 \_ /usr/bin/sudo sleep 15 > 1598 pts/0 S+ 0:00 \_ sleep 15 > > 条件を次のようにすると、 > > Defaults !use_pty > Defaults !pam_session > Defaults !pam_setcred > > 1240 ? S 0:00 xterm -class UXTerm -title ... > 1246 pts/0 Ss 0:00 \_ bash > 1639 pts/0 S+ 0:00 \_ sleep 15 > > どうやら、動作が変わって、説明が古くなったということのようです。 > 訳文は、原文のとおりにしておくのが穏当なところでしょうか。 > > Signal handling > When the command is run as a child of the sudo process, > sudo will relay signals it receives to the command. > The SIGINT and SIGQUIT signals are only relayed when the > command is being run in a new pty or when the signal was > sent by a user process, not the kernel. This prevents > the command from receiving SIGINT twice each time the user > enters control-C. Some signals, such as SIGSTOP and SIGKILL, > cannot be caught and thus will not be relayed to the command. > As a general rule, SIGTSTP should be used instead of SIGSTOP > when you wish to suspend a command being run by sudo. > > シグナルの処理 > コマンドが sudo プロセスの子プロセスとして実行されているとき、 > sudo は自分が受け取ったシグナルをそのコマンドに中継する。 > ただし、SIGINT や SIGQUIT シグナルが中継されるのは、その > コマンドが新たに開いた pty で実行されているときか、シグナルが > カーネルではなく、ユーザ・プロセスによって送出されたときだけ > である。そうなっていることで、ユーザが control-C を入力する > たびに、コマンドが SIGINT シグナルを二重に受け取らないように > しているのだ。 SIGSTOP や SIGKILL のようないくつかのシグナルは、 > 捕獲できないので、コマンドに中継されることもない。だから、 > sudo によって実行されているコマンドをサスペンドしたかったら、 > 原則として、SIGSTOP ではなく、SIGTSTP コマンドを使用するべき > である。 > > As a special case, sudo will not relay signals that were sent > by the command it is running. This prevents the command from > accidentally killing itself. On some systems, the reboot(8) > command sends SIGTERM to all non-system processes other than > itself before rebooting the system. This prevents sudo from > relaying the SIGTERM signal it received back to reboot(8), > which might then exit before the system was actually rebooted, > leaving it in a half-dead state similar to single user mode. > Note, however, that this check only applies to the command > run by sudo and not any other processes that the command > may create. As a result, running a script that calls reboot(8) > or shutdown(8) via sudo may cause the system to end up in this > undefined state unless the reboot(8) or shutdown(8) are run > using the exec() family of functions instead of system() (which > interposes a shell between the command and the calling process). > > sudo は原則として、自分が受け取ったシグナルを子プロセスに > 中継するわけだが、 自分が実行しているコマンドから来たシグナルは、 > 中継しないという例外がある。コマンドが意図に反して自分自身を > 殺してしまわないようにしているのだ。システムによっては、 > reboot(8) コマンドが、システムをリブートする前に、 自分自身を > 除くすべてのノン・システム・プロセスに SIGTERM を送るものがある。 > そうした場合も、中継の抑制があるため、sudo は自分が受け取った > SIGTERM シグナルを reboot(8) に送り返さない。もし送り返すように > なっていたら、システムが実際にリブートする前に reboot(8) が > 終了して、システムがシングルユーザ・モードによく似た半分死んだ > 状態 (half-dead state) に陥ってしまうだろう。とは言え、 > 注意していただきたいが、 この中継の抑制が行われるのは、 > sudo によって直接実行されるコマンドに対してのみであり、 > そのコマンドが生成するかもしれない他のどんなプロセスに対しても > 当てはまらない。 それ故、reboot(8) や shutdown(8) を呼び出す > スクリプトを sudo 経由で実行すると、システムがそうしたわけの > わからない状態に陥ることがある。 reboot(8) や shutdown(8) の > 実行に exec() ファミリーの関数ではなく、 system() 関数を使用して > いると、(system() は、呼び出しプロセスとコマンドの間にシェルを > 挟むため) そうしたことが起こりかねないのだ。 > > If no I/O logging plugins are loaded and the policy plugin > has not defined a close() function, set a command timeout or > required that the command be run in a new pty, sudo may execute > the command directly instead of running it as a child process. > > 入出力ロギング・プラグインがロードされていない場合に、 > ポリシー・プラグインが close() 関数を定義してもいず、 > コマンドのタイムアウトを設定していることもなく、コマンドを > 新たに開いた pty で実行することを要求してもいなかったならば、 > sudo は、コマンドを子プロセスとしてではなく、直接実行する > かもしれない。 > > 最後の文ですが、"not ... or ..." は "neither ... nor .." でしょうから、 > 上のように訳しましたが、これは「プロセス・モデル」で言ったのと同じ > 問題があると思います。 > > なお、"set a command timeout" というのがわからなかったのですが、 > これは sudo_plugin.man に説明がありました。よくわかりませんけれど。 > > ついでに、もう一つ。-p オプションの説明の最後の部分です。 > > The custom prompt will override the system password prompt > on systems that support PAM unless the passprompt_override > flag is disabled in sudoers. > > 自家特製のプロンプトが、 PAM をサポートしているシステムで > システムのパスワードプロンプトに置き替わるのは、 sudoers で > passprompt_override フラグが無効になっていない場合である > > これも実際の動作とは違うような気がします。/etc/sudoers で > "Defaults !passprompt_override" と書いても (man sudoers によれば、 > それがデフォルト)、-p オプションでパスワード・プロンプトの変更が > できてしまいます。まあ、だれも気にしないことでしょうが。 > > -- > 長南洋一 > > _______________________________________________ > linuxjm-discuss mailing list > linux****@lists***** > http://lists.osdn.me/mailman/listinfo/linuxjm-discuss
Fork