なぜ補助グループにsetgid（）する必要があるのですか？

set*gid()非常にまれな場合を除いて、さまざまなシステムコールには、グループを変更するための特権が必要です。プライマリグループをプロセスの補足グループの1つに変更することは、それらの1つではないようです。たとえば、newgrp/ sgコマンドは、プライマリグループを切り替えるために特権を昇格する必要があります。

setgid()/ setegid()/ setregid()/ setfsgid()特権のない補足グループへの切り替えを許可しない理由はありますか？もしそうなら、理由は何ですか？

security group system-calls

— ウィリアム・ヘイ
ソース

どちらかわかりません。ファイルを補足グループの1つにchgrpできるので、noexec、nosuidのない領域への書き込みアクセス権がある場合は、（/usr/bin/envsetgid権限でのコピーを作成することにより）その制限を回避できます。

— ステファンChazelas

ww newgrpコマンドはすでにAFAICTでこれを実行していますが、外部プログラムの生成が常に実行したいわけではありません。

— ウィリアムヘイ

newgrp/sgは、プロセスの補足グループリストではなく、アカウントデータベースを指すことに注意してください。

— ステファンChazelas

gidが補足IDのリストにもない場合、setgid()許可するとグループのメンバーシップを離れることができます（これはセキュリティ上の問題になります）が、上記と同じsetgid実行可能トリックを使用してこれを行うこともできます。そしてあなたのgidは通常あなたの補足リストにもあります（initgroups(3)そのためにgid引数を取ります）。

— ステファンChazelas

回答:

もちろん、ここでの基本的な問題は、ファイルシステムの権限チェックが（実効UIDと）実効GIDと補足GIDの組み合わせに基づいていることです。したがって、ファイル権限チェックの観点から見ると、実効GIDは補足GIDと同等であり、OPの質問につながります。（ちなみに、Linuxの場合は、実効UIDとGIDではなく、実際にはファイルシステムの権限チェックで使用されるのはファイルシステムのUID / GIDですが、前者のIDはほとんどの場合後者のIDと同じ値です。）

したがって、実際の/有効な/保存されたセットのGIDが補足のGIDと同等でない場合がいくつかあるはずです。（通常のset * gid（）アクセス許可規則では、非特権プロセスがこれらのGIDのいずれかを他の2つと同じ値に変更できるため、実際の/有効な/保存済みのGIDをグループ化しています。）

実際、そのようなケースはいくつかあります。access（2）は、プロセスの実際のユーザーIDとグループIDに基づいてチェックを行います。非特権ユーザーが実際のグループIDを、実効または保存セットGIDではない補足GIDの1つと同じに変更できた場合、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）を参照してください。

— mtk
ソース

注：@mtkはThe Linux Programming Interfaceの作者です。

— ステファンChazelas

有効なgidは、新しいファイルのグループ所有権を決定します。しかし、その後、そのグループを補足的なgidの1つに変更できます（また、プロセスが効果的にsetgid（）を実行できるようにsetgidビットを指定します）。したがって、それは弱い理由のように思えます。

— ステファンChazelas

@StéphaneChazelas：同意しました、少し弱いです。OTOHでは、これが2ステップのプロセスになりました（そして、私はここに到達します）は、奇妙なレースの可能性があります。しかし、その場合を除いて、私が上で述べた他のものがあります。この設計上の決定があった理由は正確にはわかりません。おそらくそれはaccess（2）でした。これはAPIの古くからの部分だからです。他の多くは後で到着した（またはLinux固有）か、（私は推測します）補足GIDが追加されたときにBSDに存在しませんでした。または、多分、それは単に歴史的な行動を保存することでした。その点をお答えになりましたね。

— mtk

その理由は主に歴史的なものだと思います。補足グループは4.2BSD（1983年頃）まで追加されませんでした。それ以前は、本当の効果的なuidとgidしかありませんでした。

setuid / setgidの動作は完全に対称的であり、そうでない理由はありませんでした。あなたは持つユーザに切り替えるだろうsuと、そのグループをsg/ newgrpすべてのsetuid実行。ユーザーグループメンバーシップに関する情報は、ユーザーデータベースにのみ存在し、プロセスの属性には存在しませんでした。

また、補助的なgidが追加されても、setuid / setgidインターフェースは変更されませんでした。

技術的には、ファイルシステムへの書き込みアクセス権がある場合（実行とsetuid / setgidが無効になっていない場合）、実効ユーザーIDまたは実際のユーザーIDを任意の補足GIDSに設定できます（sg/ に頼る必要はnewgrpありません。ユーザーデータベースで定義されたグループへの変更を許可します。これは、プロセスの補足的なギドのリストと必ずしも同じではありません）。

cp /usr/bin/env .
chgrp any-sup-group env
chmod g+s ./env

そして実行するとenv、あなたのエジッドはに切り替わりますany-sup-group。

— ステファンシャゼラス
ソース