このglibc問題を回避する最良の方法は何でしょうか？
私は、ファイル機能を使用して、setuid-rootバイナリ（たとえば/bin/ping、CAP_NET_RAWなど）の必要性のほとんどを排除するGentoo Hardenedボックスを管理しています。 実際、私が残した唯一のバイナリはこれです： abraxas ~ # find / -xdev -type f -perm -u=s /usr/lib64/misc/glibc/pt_chown abraxas ~ # setuidビットを削除するか、ルートファイルシステムを再マウントするnosuidと、sshdとGNU Screenが動作を停止しますgrantpt(3)。これらはマスターの擬似端末を呼び出し、glibcはこのプログラムを実行してスレーブの擬似端末をchownおよびchmodする/dev/pts/ためです。失敗します。 問題は、grantpt(3)Linuxの場合、devptsファイルシステムがマウントされていると、そのようなヘルパーバイナリは不要であると明示的に記載されているマンページです。カーネルは、スレーブのUIDとGIDを、/dev/ptmx（呼び出しによりgetpt(3)）開いたプロセスの実際のUIDとGIDに自動的に設定します。 これを示すために、小さなサンプルプログラムを作成しました。 #include <string.h> #include <sys/types.h> #include <sys/stat.h> #include <stdlib.h> #include <stdio.h> #include <unistd.h> int main(void) { int master; char slave[16]; struct stat slavestat; if ((master = getpt()) < 0) { …