☰

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

tag-icon • tag-icon solaris opensolaris smf illumos smartos
¿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 familiarizados con SmartOS, es una distribución de IllumOS basada en la nube con KVM. Pero esencialmente es como Solaris y hereda de OpenSolaris. Entonces, incluso si no ha usado SmartOS, espero aprovechar algunos conocimientos de Solaris sobre 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 sin privilegios 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?

Respuesta1

Porque svccfg(1M) está roto y yo 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 se 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. Este se integró bajoeste compromiso, y lo utilizan (al menos) los productos de almacenamiento Sun ZFS para almacenar cosas como contraseñas LDAP.

Como parte de ese trabajo, queríamos asegurarnos de que incluso los usuarios privilegiados que pudieran leer estos valores no los expusieran accidentalmente al exportar el estado de un servicio o al crear un archivo del repositorio SMF. Entonces 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.

Lamentablemente, esta restricción no se aplica correctamente; en este caso, simplemente nos negamos a exportar excepto unas pocas propiedades seleccionadas 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 cuando lleguemos al punto relevante, ya no tendremos el contexto necesario para saber que ya lo has superado. Incluso es justo preguntarse si se debería exigir este indicador 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 de la vista de los demás a menos que sea explícitamente deseado. Pero en versiones anteriores de S10, el XML exportado y los archivos lo contenían, por lo que definitivamente era un cambio incompatible. Se te perdonará que te molestes por eso. Pero el verdadero problema aquí es que -a no funciona cuando el grupo de propiedades en cuestión es "general". No tengo idea de cómo eres la primera persona en golpear esto.

Puedes seguir este número 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 mediante svcprop(1) si es necesario. Tienes mis disculpas. Gracias a Deirdre Straughan por llamar mi atención sobre esta pregunta.

información relacionada