Cソースファイルでコンパイルされた実行可能なバイナリがあります。
実行可能ファイルには setuid 権限があります。
実行可能ファイルの所有者根、使えます
setuid(geteuid());
ファイルのコンパイル時に設定実際のUID実行可能ファイルを実行するプロセスは次のとおりです。根。その実行ファイルを実行している人は誰でも次のように実行できます。根。
ただし、実行ファイルの所有者根。与えようとするとうまくいきません。テストユーザー実行可能ファイルの所有権（およびsetuidを再度含めるための権限の変更）このドキュメントページを読んだ後（1、2、サム）そして読んでくださいこの投稿、私はこれがsetuid(new_euid)変更のために行われたことを知っていました有効なUID代わりに実際のUID実行可能ファイルを実行するプロセスの名前。偶然にもある状況では（有効なUIDroot）、setuid(new_euid)また設定されています実際のUIDそして保存されたUID実行可能ファイルを実行するプロセスですnew_euid。
setreuid代わりに、以下を使用して問題を解決しましたsetuid。
setreuid(geteuid(), geteuid());
これにより、以下を設定できます。実際のUIDプロセスの有効なUID(実行ファイルの所有者)とリセット有効なUIDその価値に合わせて（冗長性）。
私はこれが特定の条件で動作することを知っていますが、変更したりsetuid()使用したり、あまり混乱しないでsetreuid()よりsetresuid()適切です。seteuid()実際のUID、保存されたUIDまたは有効なUIDいつも働くので理想的ですか？
追加：私が知る限り、これは説明されたものと同じ違いでseteuid()あるようです。setuid()ここ（有効なUIDルート）です。 root権限を持つプログラムが権限を削除した後に権限を再取得することはできませんか（3つのUIDがすべて同じ値に変更されるためsetuid()）。それでは、setuid()他のプログラムと比較してもroot権限を持つプログラムのみを使用する必要がありますかsetresuid()？
setuid()root権限を持つプログラムがアンインストール後に権限を再取得することを許可しないという点で、これは安全であると思いますが、上記の他の機能を使用して混乱を減らすために動作を達成できます。
もう一つのことgetuid()が戻ってくる実際のUID手順の進行中に修正するようにsetuid()設計されています。有効なUID（特権がない限り）これも混乱しています。
ベストアンサー1
これらすべての後ろにハッカーの歴史があるかもしれません。あなたが言ったように、setreuid()もっと確実に規格に規定されている、私はそれを使用します。次のステップは、戻り値を慎重に確認し、getuid()を使用して確認することですgeteuid()。
setresuid()POSIXにはないので広く使われないかもしれません（FreeBSDとOpenBSDにはあるようです）。実装がsetreuid()文書と一致する場合、保存されたUIDを明示的に設定する必要はありませんsetreuid()。
実際のユーザーIDが設定されているか（ruidが-1ではない）、有効なユーザーIDが実際のユーザーIDと異なる値に設定されている場合は、現在のプロセスによって保存されたset-user-IDを設定する必要があります。新しい有効ユーザーIDと同じです。
その後、可能であれば、別々に実行される特権プロセスを好み、setuidプログラムを使用せずにソケットを介して通信することをお勧めします。プロセスから子プロセスに継承される多くのものがあり、setuidを使用すると、低い権限を持つプロセスがそれをより高い権限に設定できます。