Pourquoi le manifeste SMF perd-il des données de configuration lors de l'exportation sur SmartOS?

J'exécute un processus serveur sous SMF (Server Management Facility) sur l'image SmartOS Base64 1.8.1 de Joyent.

Pour ceux qui ne maîtrisent pas SmartOS, il s'agit d'une distribution basée sur le cloud d'IllumOS avec KVM. Mais c'est essentiellement comme Solaris et hérite d'OpenSolaris. Donc, même si vous n'avez pas utilisé SmartOS, j'espère pouvoir utiliser certaines connaissances de Solaris sur ServerFault.

Mon problème est que je veux qu'un utilisateur non privilégié soit autorisé à redémarrer un service qu'il possède. J'ai déterminé comment le faire en utilisant RBAC et en ajoutant une autorisation à /etc/security/auth_attret en associant cette autorisation à mon utilisateur.

J'ai ensuite ajouté ce qui suit à mon manifeste SMF pour le service:

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

Et cela fonctionne bien lors de l'importation. Mon utilisateur non privilégié est autorisé à redémarrer, démarrer et arrêter son propre processus serveur (c'est pour les déploiements de code automatisés).

Cependant, si j'exporte le manifeste SMF, ces données de configuration ont disparu ... tout ce que je vois dans cette section est le suivant:

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

Quelqu'un sait-il pourquoi cela se produit? Ma syntaxe est-elle incorrecte ou est-ce que j'utilise simplement SMF de manière incorrecte?

Parce que svccfg (1M) est cassé, et je l'ai cassé.

En 2007, j'ai ajouté une fonctionnalité à SMF qui permettait aux groupes de propriétés pouvant contenir des informations sensibles, lisibles uniquement par les utilisateurs disposant des privilèges appropriés. L'idée était que vous pouviez ajouter une propriété "read_authorization" à un groupe de propriétés, et quiconque n'était ni privilégié (fondamentalement, root) ni en possession d'une des autorisations nommées par cette propriété ne pourrait pas lire les valeurs d'une propriété dans le groupe. Il a été intégré dans cette validation et est utilisé (au moins) par les produits de stockage Sun ZFS pour stocker des éléments tels que les mots de passe LDAP.

Dans le cadre de ce travail, nous voulions nous assurer que même les utilisateurs privilégiés qui pouvaient lire ces valeurs ne les exposeraient pas accidentellement en exportant l'état d'un service ou en créant une archive du référentiel SMF. J'ai donc ajouté l'indicateur '-a' aux commandes d'exportation et d'archivage dans svccfg qui exporterait explicitement toutes les valeurs de propriété et j'ai changé la valeur par défaut pour exclure celles qui étaient protégées en lecture.

Malheureusement, cette restriction n'est pas appliquée correctement; dans ce cas, nous refusons tout simplement d'exporter toutes les propriétés du groupe de propriétés "général" sauf quelques-unes avec des valeurs. Le reste est exporté sans aucune valeur, c'est ce que vous voyez. Et malheureusement, l'utilisation de l'option -a n'aidera pas ici, car au moment où nous atteignons le point pertinent, nous n'avons plus le contexte requis pour savoir que vous avez réussi cela. Il est même juste de se demander si cet indicateur devrait être requis pour exposer ces valeurs: l'identité des autorisations qui permettent de changer l'état du service est en effet sensible et serait utile à un attaquant. Sans aucun doute, c'était dans mon esprit lorsque j'ai écrit cela, et il est raisonnable de restreindre cela du point de vue des autres, sauf si cela est explicitement souhaité. Mais dans les versions antérieures de S10, XML exporté et les archives le contenaient, donc c'était définitivement un changement incompatible. Vous seriez pardonné d'être contrarié par cela. Mais le vrai problème ici est que -a ne fonctionne pas lorsque le groupe de propriétés en question est "général". Comment tu es la première personne à frapper ça, je ne sais pas.

Vous pouvez suivre ce problème sur sa page, ici . En attendant, vous pouvez envisager de contourner ce problème en ajoutant manuellement les valeurs des propriétés dans le XML généré. Notez que vous pouvez également les lire via svcprop (1) si nécessaire. Vous avez mes excuses. Merci à Deirdre Straughan d'avoir porté cette question à mon attention.