AIエージェントのサブプロセス内でのみ権限エラーが発生する原因は何ですか？

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

What Causes Permission Errors Only Inside AI Agent Subprocesses? - Zima Store Online

サブプロセス限定の権限エラーは、エージェントが異なるユーザー、環境、名前空間、ファイルシステムビュー、またはセキュリティポリシーで子プロセスを起動したときに発生します。

エージェントプロセスは家庭内のファイルを読み取ったり、ツールを正常に呼び出したりできても、同じ操作をシェル、Pythonワーカー、コンテナ、またはサンドボックス経由で実行すると「権限が拒否されました」と表示されることがあります。子プロセスでは、補助グループ、資格情報、環境変数、ケイパビリティ、ソケットアクセス、マウントの可視性、または実行権限が失われる可能性があります。コマンドテキストは同一でも、セキュリティコンテキストは同じではありません。

子プロセスでは異なるユーザーと資格情報セットを継承することがある

ランチャーは、UID、GID、補助グループ、umask、作業ディレクトリ、環境、ファイルディスクリプターを設定できます。サービスマネージャー、setuidヘルパー、コンテナ、ワーカープールは、生成されたコードを実行する前に意図的に権限を落とすことがあります。この違いは、後続の家庭内テストでも確認できます。

プロセスのセキュリティコンテキストを実践的に分析するには、Unixのモードビットだけですべてを判断せず、まずユーザー、セキュリティポリシー、名前空間を確認します。特徴としては、子プロセス内でID、グループ、umask、または資格情報の利用可能性が異なります。

親プロセスがrootで実行されていても、制限のない子プロセスが保証されるわけではありません。また、コンテナやネットワーク共有では、数値IDが異なるユーザーにマッピングされる場合があります。失敗したシステムコールで有効なユーザー情報を比較してください。自動化を進める前に、中間結果を検証可能な状態に保つ必要があります。

名前空間、マウント、サンドボックスによってファイルシステムの見え方が変わる

サブプロセスは、パスが読み取り専用、非表示、再マッピング済み、noexecでマウントされている、または別の数値IDに所有されているコンテナやサンドボックスに入ることがあります。通常のファイルが見えていても、Unixソケットやデバイスファイルが存在しない場合があります。

サンドボックスのトラブルシューティング事例では、子プロセスが必要な転送ソケットにアクセスできない場合のサンドボックスソケットの権限が示されています。ここから分かるのは、「権限が拒否されました」というエラーが、ファイルの内容だけでなく、接続性や名前空間ポリシーを指す場合もあるということです。この境界は、現実的な運用条件の下で個別に測定してください。

子プロセスから別のinode、マウントオプション、またはパスが見えている場合、ホスト側の権限を変更しても影響しないことがあります。失敗しているコンテキストの内部から、パスとマウントの識別情報を解決してください。複数のソースが限られたコンテキストを奪い合うと、その実際的な影響が現れます。

ケイパビリティと強制ポリシーによって、許可されたモードビットでも拒否されることがある

Linuxのケイパビリティはroot権限を分割します。一方、SELinux、AppArmor、seccomp、サンドボックスのルールは、所有者の読み取り権限や実行権限があっても操作を拒否できます。ネットワーク、ptrace、デバイス、マウント操作は、よくある境界です。この依存関係は、最終インターフェースでも明示したままにしてください。

ケイパビリティとセキュリティラベルのモデルでは、ケイパビリティやセキュリティラベルとともにUIDおよびGIDの制御も説明されています。これらが独立した層であるため、chmodだけではサブプロセスの失敗が変わらないことがあります。したがって、結果は元の証拠と照合して確認する必要があります。

失敗の境界が、OSによる拒否に対応しないアプリケーション生成の権限メッセージである場合があります。サンドボックスのポリシーを弱めたり、ファイルを全ユーザーに書き込み可能にしたりする前に、errno、監査ログ、正確なシステムコールを取得してください。この違いは、後続の家庭内テストでも確認できます。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

失敗した呼び出しで親と子のセキュリティコンテキストを比較する

親と子の両方で、実行ファイルのパス、引数、cwd、UID、GID、グループ、umask、環境変数名、ファイルディスクリプター、名前空間ID、マウントテーブル、パスのinode、モード、ACL、セキュリティラベル、ケイパビリティ、seccompの状態、ソケットの存在、errno、監査結果を取得します。

エージェントのケイパビリティ制御を使い、結果をエージェントのツール範囲と関連付けます。最小構成の子プロセスで再現し、ランチャー、コンテナ、サンドボックスの層を一度に1つずつ戻していきます。自動化を進める前に、中間結果を検証可能な状態に保つ必要があります。

不足しているケイパビリティ、グループ、マウント、ソケット、またはパスだけを付与してください。意図した分離を反映している制限は維持します。サブプロセスの失敗は、ホームAIの信頼境界が正しく機能している証拠である可能性があります。この境界は、現実的な運用条件の下で個別に測定してください。