代わりに、新しいユーザーIDで新しいシェルプロセスを開始します。元のシェルは、新しいシェルが完了してsuが終了するまでブロックされます。なぜですか？
答え1
簡単です。なぜならできないからです。他のプロセスのuidを変更するためのシステムコールはありません。親シェルが終了するのを待たない場合は、組み込みコマンドをsu前に追加してください。execこれにより、最初に分岐せずにシェルが直接実行されます。もちろん、間違ったパスワードを入力すると、返すシェルがないため、セッションは終了します。
答え2
すでに指摘したように、これを行う方法はありません。もちろん意味があれば方法がある。そのようなシステムコールがないという理由はありません。できない完成した。言い換えれば、コメントでmtkが述べたように無関係なプロセスのセキュリティコンテキストを変更するためにシステムコールを使用すると、発生する可能性がある混乱を想像してください。他に何もなければ、競争条件が3...2...1...で発生するのを見るでしょう。 （そして、私たちはinitセキュリティコンテキストを変更したりgetty何ができるのか理解していません。）
一つその他なぜならsu 新しいシェルを呼び出すだけでなく、。また、どのシェルが起動するか（-sまたは使用）を制御し、--shell（GNUで）/ -/-lおよび--login（-c）引数を--command介して引数を渡すことで制御できます。 suに渡される引数は、新しいシェルの環境にも影響します。だからあなたはできる親プロセスのセキュリティコンテキストを変更するだけで、必ずしもそうする必要はありません。考えるこの方法。