要約

  • RFC 3179 は SNMP Agent の Script MIB と言語別ランタイムの間に SMX を置いた。231 は running、停止、再開といった状態を確認できたが、スクリプトの終了を示さなかった。
  • 532/533 は中間結果、536/537 はエラー、538 は終了を担った。非致命エラーの後に処理が続くため、単一の成否欄では実行経過を再現できない。
  • 正常に終了し結果が保存されても、結果バイトの意味と対象ネットワークの変化は別途確認が必要だった。ランタイムは自分が観測していない効果を証明できない。

Script MIB は実行エンジンを抱え込まなかった

2001 年 10 月の RFC 3179 は Script MIB Extensibility Protocol Version 1.1 を Experimental として公開した。文書自身が Internet Standard ではないと明記している。したがって、ここから読み取れるのはプロトコル設計であり、特定製品の実装や普及、運用上の成功ではない。

基礎にある RFC 3165 の Script MIB は、SNMP 管理者がスクリプトを登録し、引数を渡し、複数インスタンスを起動し、制御し、結果を回収するための共通面だった。ところが Java や Tcl などの処理系をすべて Agent に組み込めば、管理インターフェースが言語固有の都合に引きずられる。SMX は言語に依存しない MIB 実装と、言語を実行する別プロセスを結んだ。

分離された両者は、同じ事実を持たない。Agent は管理者の要求と MIB オブジェクトを知る。ランタイムはコードをロードできるか、どのセキュリティ・プロファイルで動かすか、インスタンスがどの状態かを知る。両者の間の応答が証明するのは、この境界を越えた一つの状態変化だけである。

接続と hello の後には、start、suspend、resume、abort、status が並ぶ。三桁の応答は簡潔だが、簡潔さは広い意味を許さない。コードを受け取った側、対象コマンド、成立した時点を保存してこそ証拠になる。

231 は仕事の入口を閉じた

start を受けたランタイムは構文、スクリプト、プロファイルを調べ、実行インスタンスを作る。231 はそのインスタンスが running に達した後で返る。通信路が単にパケットを届けただけではなく、ランタイムが要求を解釈し実行状態を作ったことを示す、意味のある応答だった。

しかし、その時点では結果はまだない。処理は長く続くかもしれず、依存先を待つかもしれず、途中値を出した後で止まるかもしれない。エラーから回復して継続する場合も、正常に終わりながら呼び出し側が理解できない値を返す場合もある。231 が強いのは起動の証拠としてであって、完了の証拠としてではない。

suspend では停止状態に到達したとき、またはすでに停止中なら 231 が返る。resume では再び running になったときに返る。status は観測した状態を知らせ、abort は中止後または既に中止済みなら 232 を返す。どの応答も制御操作を閉じるが、対象装置の最終状態を閉じない。

運用画面が「受付」「実行中」「完了」「有効」を一つの緑色へ畳むと、この範囲が消える。起動成功数は増えても、終了しないインスタンスは見えなくなる。RFC の状態機械は、後の出来事を前の応答へ逆流させない仕組みだった。

出力と終了には別の時刻があった

532 は中間結果を送り、533 は同じ種類の結果に加えて Script MIB の smScriptResult 通知を求めた。ランタイムから Agent へ値が届くことと、管理側へ通知が投影されることは別のイベントだった。

中間結果は真実でも最終回答とは限らない。診断が調べ終えた範囲だけを報告することも、変更手順が最初の段階だけを終えることもある。値を受信した後の沈黙は完了ではなく、単に後続証拠が欠けている状態である。

RFC 3165 では引数と直接結果が OCTET STRING だった。MIB はバイトの形式や意味を決めず、呼び出し側が理解する責任を負った。複雑な出力を別の MIB で公開したり、大きな結果の所在を URL で返したりもできる。URL を受け取ったこと、取得できたこと、内容が完全だったこと、正しく解釈したことは、それぞれ別の受領証を要する。

終了したスクリプトの履歴は後から結果を回収するために残せた。オフライン運用には便利だが、表が満ちればエージングされる。実行が終了したという過去の事実と、監査時に結果が利用可能であるという現在の事実は一致しない。

エラーは必ずしも処理を終わらせなかった

536 はエラーを伝え、537 は smScriptException 通知も発生させるエラーを伝えた。どちらも致命的な場合と非致命的な場合がある。非致命なら実行は続き、致命ならその後に終了が来る。

よって、ログにエラーがあるだけでは実行状態を決められない。通知生成と受信も同一ではない。ランタイム内の出来事、MIB への投影、その後のインスタンス状態を順番付きで保たなければ、回復した処理と停止した処理を区別できない。

バージョン 1.1 は終了を表す 538 を追加し、従来の正常終了 534 と異常終了 535 を非推奨にした。結果やエラーを専用メッセージで表し、最後に一つの終了イベントを置く構成である。終了ラベル一個に出力、原因、最終状態のすべてを詰め込まなくてよくなった。

それでも 538 が証明するのはランタイム内の終端である。正しい仕事だったかを判断するには、コード、引数、先行する出力とエラー、解釈スキーマが必要になる。ネットワーク効果を判断するには、設定の読み戻し、稼働状態、カウンター、トラフィック、到達性など、対象に応じた外部観測が要る。

権限の狭さと処理の正しさは違う

RFC 3179 は launch owner を OS のセキュリティ・プロファイルとランタイムのプロファイルへ結び付ける考えを示した。OS は制限されたプロセス環境を作り、安全なインタープリタや仮想機械は言語側の能力を抑えられる。

これは「何に触れられるか」への回答であり、「何を正しく計算したか」への回答ではない。最小権限のスクリプトも誤る。正しいコードも誤った引数や対象を受け取る。正式な所有者も古い版を選ぶ。正常終了後に遠隔装置が操作を拒否することもある。

ローカルのスクリプト保管領域も重要だった。SNMP Agent 以外が書き込めれば、攻撃者が内容を置き換え、特権を持つランタイムに任意コードを実行させられる。管理名を知っていることは、実行バイトを知っていることではない。名前、内容、ロード時刻、インスタンスを結ぶ必要がある。

1.1 は TCP に加えて双方向 pipe を好ましいトランスポートとして追加した。1.0 が共有秘密を OS 環境変数で渡したことにリスクがあったためである。pipe はその露出を除くが、ファイル権限、プロセスの身元、SNMP の認可まで自動的に保証しない。

後の RFC 3411、3414、3415 は SNMPv3 の構成、ユーザー・ベースのセキュリティ、ビュー・ベースのアクセス制御を説明する。これらを SMX 固有機能として過去へ持ち込むことはできない。MIB 操作が認可されたことも、スクリプトの全外部効果が認可された証明ではない。

監査記録は 231 より前から 538 より後まで続く

まず不変のコード版、所有者、引数、対象、プロファイル、要求時刻を保存する。次にインスタンスと 231 を結び、532/533、致命性付きの 536/537、538 を順番通り残す。履歴の保持期間、結果を回収した主体と時刻も欠かせない。

その後に解釈がある。消費者は OCTET STRING に用いたスキーマを示す。URL なら参照、取得、完全性、解析を分ける。通知なら生成と到着を分ける。

最後に管理対象自身を読む。設定変更なら権威ある設定面と必要な稼働面を確認する。診断なら観測期間と分母を添える。トラフィック操作なら後続カウンターやパケットを調べる。ランタイム・プロトコルは見ていない現実を代わりに証明できない。

RFC 3179 の意義は遠隔スクリプトを礼賛したことではない。コマンド、状態、出力、エラー、終了を別々の出来事にしたことだ。結果の意味は呼び出し側に、ネットワークの現実は対象側に残った。自動化を説明可能にするのは、受領証を増やすことより、各受領証を越権させないことである。

情報源と限界

RFC 3179 の状態、手続き、非同期応答、トランスポート、安全上の注意は RFC 3179 本文、RFC Editor 記録、HTML 版、IETF 履歴、正誤表検索による。Script MIB、結果の意味、実行履歴は RFC 3165 本文、記録、HTML 版に基づく。置き換え前との比較は RFC 2593 本文と記録に限定した。

後代の SNMP 文脈は SNMP アーキテクチャ、ユーザー・ベースのセキュリティ・モデル、ビュー・ベースのアクセス制御モデルから得た。要求、状態、証拠、結果の分離には、Lu Heng の稼働コード優先、現実の層、最小初期仕様に関する論考を用いた。16 URL は 2026 年 10 月 2 日 Asia/Shanghai で凍結した。

これらは設計を示すが、実装、運用者、スクリプト、装置、プロファイル、攻撃、節約、ネットワーク変更、サービス結果を示さない。証拠連鎖は Sofia Ren の編集分析であり、RFC 著者や機関の主張ではない。