web-dev-qa-db-ja.com

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

JoyentのBase641.8.1 SmartOSイメージでSMF（サーバー管理機能）の下でサーバープロセスを実行しています。

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を間違って使用していますか？

solarisopensolarissmfillumossmartos
10
Scott

Svccfg（1M）が壊れているので、私はそれを壊しました。

2007年に、SMFに機能を追加して、機密情報を含む可能性のあるプロパティグループを許可し、適切な権限を持つユーザーのみが読み取り可能にしました。 「read_authorization」プロパティをプロパティグループに追加でき、特権（基本的にはroot）も、そのプロパティによって指定された承認の1つも所有していない人は、プロパティの値を読み取ることができないという考えでした。グループで。これは this commit の下に統合され、LDAPパスワードなどを格納するために（少なくとも）SunZFSストレージ製品によって使用されます。

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

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

この問題は、こちらのページで確認できます 。それまでの間、生成されたXMLにプロパティの値を手動で追加することで、この問題を回避することを検討できます。必要に応じて、svcprop（1）を介してそれらを読み取ることもできることに注意してください。お詫び申し上げます。この質問に注意を向けてくれたDeirdreStraughanに感謝します。

16
Keith M Wesolowski