☰

SMF マニフェストを SmartOS にエクスポートすると構成データが失われるのはなぜですか?

tag-icon • tag-icon solaris opensolaris smf illumos smartos
SMF マニフェストを SmartOS にエクスポートすると構成データが失われるのはなぜですか?

私は、Joyent の Base64 1.8.1 SmartOS イメージ上の SMF (Server Management Facility) でサーバー プロセスを実行しています。

SmartOS を知らない人のために説明すると、これは KVM を使用した IllumOS のクラウドベースのディストリビューションです。しかし、本質的には Solaris に似ており、OpenSolaris から継承されています。そのため、SmartOS を使用したことがない人でも、ServerFault で Solaris に関する知識を活用できることを期待しています。

私の問題は、権限のないユーザーが所有するサービスを再起動できるようにしたいということです。RBAC を使用して承認を追加し、その承認をユーザーに関連付けることで、これを実現する方法を見つけました/etc/security/auth_attr。

次に、サービスの SMF マニフェストに次のコードを追加しました。

<property_group name='general' type='framework'>
  <!-- Allow to be restarted-->
  <propval name='action_authorization' type='astring'
    value='solaris.smf.manage.my-server-process' />
  <!-- Allow to be started and stopped -->
  <propval name='value_authorization' type='astring'
    value='solaris.smf.manage.my-server-process' />
</property_group>

そして、これはインポートするとうまく機能します。権限のないユーザーは、独自のサーバー プロセスを再起動、開始、停止できます (これは自動コード展開用です)。

ただし、SMF マニフェストをエクスポートすると、この構成データは消えてしまいます...そのセクションに表示されるのは次のものだけです:

<property_group name='general' type='framework'>
  <property name='action_authorization' type='astring'/>
  <property name='value_authorization' type='astring'/>
</property_group>

なぜこのようなことが起こるのか、誰か知っていますか? 構文が間違っているのでしょうか、それとも単に SMF の使い方が間違っているのでしょうか?

答え1

svccfg(1M) が壊れていて、私が壊してしまったからです。

2007 年に、SMF に、適切な権限を持つユーザーだけが読み取り可能な機密情報を含むプロパティ グループを許可する機能を追加しました。そのアイデアは、プロパティ グループに「read_authorization」プロパティを追加し、権限を持たない (基本的にはルート) か、そのプロパティで指定された権限のいずれかを所有していないユーザーは、グループ内のどのプロパティの値も読み取れないようにするというものでした。これは、このコミット、そして少なくとも Sun ZFS ストレージ製品では LDAP パスワードなどを保存するために使用されます。

その作業の一環として、これらの値を読み取ることができる特権ユーザーであっても、サービスの状態をエクスポートしたり、SMF リポジトリのアーカイブを作成したりすることで、誤って値を公開しないようにしたいと考えました。そこで、すべてのプロパティ値を明示的にエクスポートする '-a' フラグを svccfg のエクスポート コマンドとアーカイブ コマンドに追加し、読み取り保護されている値を除外するようにデフォルトを変更しました。

残念ながら、この制限は正しく適用されていません。この場合、単に「一般」プロパティ グループ内の一部のプロパティを除いて、値付きでエクスポートすることを拒否します。残りのプロパティは値なしでエクスポートされます。これが、あなたが見ているものです。そして残念ながら、-a オプションを使用してもここでは役に立ちません。関連するポイントに到達するまでに、それを通過したことを知るために必要なコンテキストがなくなるためです。これらの値を公開するためにこのフラグが必要であるかどうかさえ疑問視するのは当然です。サービス状態の変更を許可する承認の ID は確かに機密であり、攻撃者にとって有用です。間違いなく、これを書いたときにそれが念頭にあったし、明示的に望まない限り、他の人のビューからそれを制限することは合理的です。しかし、S10 の以前のバージョンでは、エクスポートされた XML とアーカイブにそれが含まれていたため、それは間違いなく互換性のない変更でした。それについてあなたが怒るのは当然です。しかし、ここでの本当の問題は、問題のプロパティ グループが「一般」の場合、-a が機能しないことです。あなたがどのようにしてこれに最初に遭遇したのか、私にはわかりません。

この問題は、こちらのページでフォローできます。その間、生成された XML にプロパティの値を手動で追加することで、この問題を回避することを検討できます。必要に応じて、svcprop(1) 経由で値を読み取ることもできます。申し訳ありません。この質問を私に知らせてくれた Deirdre Straughan に感謝します。

関連情報