Setuid

一部のプログラムには、呼び出し元が通常持たないアクセスを狭く制御して与える必要があります。実行可能な通常ファイルで set-user-ID ビットを使うと、新しいプロセスがファイル所有者のユーザー ID を実効ユーザー ID として受け取る場合があります。そのプログラムは呼び出し元の情報を保持しつつ、その識別情報で認可された操作を行えます。

Setuid は一般的な「root として実行」という命令ではありません。効果は実行ファイルの所有者、オペレーティングシステム、ファイルシステムとマウントオプション、プログラムによる資格情報管理に左右されます。

所有者の実行位置にある小文字 s は、setuid と所有者実行の両方が設定されていることを示します。setuid があって所有者実行がない場合、ls -l はその位置に大文字 S を表示します。

すべてのディストリビューションが同じモードや認証設計を使うとは限りません。例に依存せず、実際のシステムを確認してください。

この機構により、慎重に作られたプログラムが要求を検証し、保護された状態へ限定的な変更を加えられます。たとえば、ローカルのパスワード変更ツールには、通常ユーザーが直接編集できない認証データへの制御されたアクセスが必要な場合があります。現代の実装は PAM、ファイルロック、ポリシーなどの保護策にも依存し、setuid だけで完全なワークフローを説明することはできません。

8進表記では、setuid は先頭の特殊ビット桁に 4 を加えます。

$ sudo chmod 4755 myfile

ここでは先頭の 4 が setuid を、755 が通常の所有者、グループ、その他のビットを設定します。ほかのモードを変えず setuid だけを削除するには chmod u-s myfile を使います。

Linux は通常、解釈されるスクリプトの setuid を有効にしません。安全に実現するには競合状態やインタープリターに関する問題があるためです。nosuid でマウントされたファイルシステムも、setuid と setgid の効果を抑止します。要件に合うなら、サービスが仲介する操作、慎重に範囲を絞った sudo ポリシー、ケーパビリティなど、より狭い仕組みを優先してください。

共有システム上での実験として、任意のシェル、インタープリター、コピーしたプログラムへ setuid を追加してはいけません。既存の setuid ファイルを監査し、隔離された破棄可能な環境だけで練習してください。