set*gid()まれな場合を除き、さまざまなシステムコールを実行するには、グループ権限を変更する必要があります。プライマリグループをプロセスのセカンダリグループの1つに変更することは、そのうちの1つではないようです。つまり、デフォルトグループを切り替えるには、newgrp/コマンドに高い権限が必要です。sg
setgid()setegid()///権限なしでセカンダリグループへの移行を許可しない理由はありますか？では、なぜそうなのでしょうか？setregid()setfsgid()
答え1
もちろん、ここでの根本的な問題は、ファイルシステム権限の検証が（有効なUIDと）有効なGIDと補足的なGIDの組み合わせに基づいていることです。したがって、ファイル権限確認の観点からは、有効なGIDは補足GIDと同じであり、これはOPの質問につながります。 （注：Linuxについて話している場合、ファイルシステム権限の確認は実際には有効なUIDとGIDの代わりにファイルシステムUID / GIDを使用しますが、電子IDはほぼ常に後者IDと同じ値を持ちます。）
したがって、実際/有効/セーブセットGIDが補足GIDと等しくない状況が発生する必要があります。 （通常のset * gid（）権限ルールは、許可されていないプロセスがこれらのGIDの1つを他の2つのGIDの1つと同じ値に変更できることを示しているため、実際/有効/セーブセットGIDを一緒にグループ化します。）
実際、そのような例がいくつかあります。プロセスに応じてaccess(2)本物ユーザーIDとグループID。権限のないユーザーが実際のグループIDを補足GIDの1つ（有効または保存されたセットGIDではない）と同じように変更できる場合は、access（2）の動作を操作できます。
他の同様の状況があります。 Linuxを見るmkdir(2) のマニュアルページ、例えば。 set-GIDモードビットが親ディレクトリに設定されているかどうかに応じて、そのディレクトリに作成された新しいファイルは、生成プロセスの有効GIDからグループ所有権を取得します。同様に、権限のないプロセスが有効なGIDをセカンダリGIDの1つに変更できる場合は、予期しない方法で新しいファイルのグループ所有権を操作できます。同様の説明がmknod（2）にも適用され、System V IPCはsemget（2）、shmget（2）、およびmsgget（2）を呼び出します。
実際/有効/セーブセットGIDが補足GIDと同じではないいくつかのLinux関連ケースもあります。バラよりprocess_vm_readv(2)たとえば、prlimit(2) です。
答え2
その理由は主に歴史的だと思います。補足グループは4.2BSD（1983年頃）まで追加されていません。以前は実用的で有効なuidとgidしかありませんでした。
setuid/setgidの動作は完全に対称なので、非対称である理由はありません。ユーザー切り替えを使用しsuてsg/ newgrpall setuid実行可能ファイルを使用してグループ化できます。ユーザーグループメンバーシップに関する情報は、プロセス属性ではなくユーザーデータベースにのみあります。
補足 gid が追加されたとき、 setuid/setgid インターフェイスは変更されませんでした。
技術的には、ファイルシステムへの書き込みアクセス権がある場合（execとsetuid / setgidが無効になっていない場合）、有効または実際のユーザーIDをセカンダリgidに設定できるようになりました（/ sgbtwnewgrpに依存しない）。ユーザーデータベースで定義されているグループであり、プロセスの補足のgidリストと必ずしも同じである必要はありません）。
cp /usr/bin/env .
chgrp any-sup-group env
chmod g+s ./env
実行後はenvEPIDがany-sup-group。