¿Por qué el manifiesto SMF pierde datos de configuración cuando se exporta en SmartOS?

Estoy ejecutando un proceso de servidor bajo SMF (Server Management Facility) en la imagen SmartOS Base64 1.8.1 de Joyent.

Para aquellos que no están interesados ​​en SmartOS, es una distribución basada en la nube de IllumOS con KVM. Pero esencialmente es como Solaris y hereda de OpenSolaris. Entonces, incluso si no ha utilizado SmartOS, espero aprovechar algunos conocimientos de Solaris en ServerFault.

Mi problema es que quiero que un usuario sin privilegios pueda reiniciar un servicio de su propiedad. He descubierto cómo hacerlo usando RBAC y agregando una autorización /etc/security/auth_attry asociando esa autorización con mi usuario.

Luego agregué lo siguiente a mi manifiesto SMF para el servicio:

<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>

Y esto funciona bien cuando se importa. Mi usuario no privilegiado puede reiniciar, iniciar y detener su propio proceso de servidor (esto es para implementaciones de código automatizadas).

Sin embargo, si exporto el manifiesto SMF, estos datos de configuración desaparecen ... todo lo que veo en esa sección es esto:

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

¿Alguien sabe por qué ocurre esto? ¿Mi sintaxis es incorrecta o simplemente estoy usando SMF incorrectamente?

Porque svccfg (1M) está roto, y lo rompí.

En 2007, agregué una función a SMF que permitía grupos de propiedades que podían contener información confidencial, legible solo por usuarios con los privilegios adecuados. La idea era que podía agregar una propiedad "read_authorization" a un grupo de propiedades, y cualquiera que no tuviera privilegios (básicamente, root) ni estuviera en posesión de una de las autorizaciones nombradas por esa propiedad no podría leer los valores de ninguna propiedad en el grupo. Esto se integró en esta confirmación y es utilizado (al menos) por los productos de almacenamiento Sun ZFS para almacenar cosas como las contraseñas LDAP.

Como parte de ese trabajo, queríamos asegurarnos de que incluso los usuarios privilegiados que podían leer estos valores no los expondrían accidentalmente exportando el estado de un servicio o creando un archivo del repositorio SMF. Así que agregué el indicador '-a' a los comandos de exportación y archivo en svccfg que exportarían explícitamente todos los valores de propiedad, y cambié el valor predeterminado para excluir cualquiera que estuviera protegido contra lectura.

Desafortunadamente, esta restricción no se aplica correctamente; en este caso, simplemente nos negamos a exportar algunas propiedades que no sean selectas en el grupo de propiedades "general" con valores. El resto se exporta sin ningún valor, que es lo que estás viendo. Y desafortunadamente, usar la opción -a no ayudará aquí, porque para cuando lleguemos al punto relevante, ya no tenemos el contexto requerido para saber que lo has pasado. Incluso es justo cuestionar si este indicador debería ser necesario para exponer estos valores: la identidad de las autorizaciones que permiten cambiar el estado del servicio es realmente sensible y sería útil para un atacante. Sin duda, eso estaba en mi mente cuando escribí esto, y es razonable restringirlo desde el punto de vista de los demás a menos que se desee explícitamente. Pero en versiones anteriores de S10, XML y archivos exportados lo contenían, por lo que definitivamente fue un cambio incompatible. Te perdonarían por estar molesto por eso. Pero el verdadero problema aquí es que -a no funciona cuando el grupo de propiedades en cuestión es "general". Cómo eres la primera persona en golpear esto, no tengo idea.

Puede seguir este problema en su página, aquí . Mientras tanto, puede considerar solucionarlo agregando manualmente los valores de las propiedades en el XML generado. Tenga en cuenta que también puede leerlos a través de svcprop (1) si es necesario. Tienes mis disculpas. Gracias a Deirdre Straughan por hacerme esta pregunta.