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

JoyentのBase64 1.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を誤って使用していますか？

svccfg（1M）が壊れて、壊れたからです。

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

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

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

この問題については、こちらのページをご覧ください。当面は、生成されたXMLにプロパティの値を手動で追加することで、回避策を検討できます。必要に応じて、svcprop（1）を使用して読み取ることもできます。お詫び申し上げます。この質問を取り上げてくれたDeirdre Straughanに感謝します。