Warum verliert das SMF-Manifest beim Export unter SmartOS Konfigurationsdaten?

Ich führe einen Serverprozess unter SMF (Server Management Facility) auf Joyents Base64 1.8.1 SmartOS-Image aus.

Für diejenigen, die nicht mit SmartOS vertraut sind, ist es eine Cloud-basierte Distribution von IllumOS mit KVM. Aber im Wesentlichen ist es wie Solaris und erbt von OpenSolaris. Selbst wenn Sie SmartOS nicht verwendet haben, hoffe ich, dass Sie einige Solaris-Kenntnisse über ServerFault nutzen können.

Mein Problem ist, dass ich möchte, dass ein nicht privilegierter Benutzer einen Dienst, den er besitzt, neu starten darf. Ich habe herausgefunden, wie das geht, indem ich RBAC verwendet und eine Berechtigung zu /etc/security/auth_attrmeinem Benutzer hinzugefügt und dieser Berechtigung zugeordnet habe.

Ich habe dann meinem SMF-Manifest für den Dienst Folgendes hinzugefügt:

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

Und das funktioniert gut, wenn es importiert wird. Mein nicht privilegierter Benutzer darf seinen eigenen Serverprozess neu starten, starten und stoppen (dies gilt für automatisierte Codebereitstellungen).

Wenn ich jedoch das SMF-Manifest exportiere, sind diese Konfigurationsdaten nicht mehr vorhanden. In diesem Abschnitt wird lediglich Folgendes angezeigt:

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

Weiß jemand, warum das passiert? Ist meine Syntax falsch oder verwende ich SMF einfach falsch?

Weil svccfg (1M) kaputt ist und ich es kaputt gemacht habe.

Bereits 2007 habe ich SMF eine Funktion hinzugefügt, die Eigenschaftsgruppen mit vertraulichen Informationen zulässt, die nur von Benutzern mit entsprechenden Berechtigungen gelesen werden können. Die Idee war, dass Sie einer Eigenschaftsgruppe eine "read_authorization" -Eigenschaft hinzufügen können und jeder, der weder privilegiert (im Grunde root) noch im Besitz einer der von dieser Eigenschaft genannten Berechtigungen war, die Werte einer Eigenschaft nicht lesen kann in der Gruppe. Dies wurde im Rahmen dieses Commits integriert und wird (zumindest) von den Sun ZFS-Speicherprodukten zum Speichern von Dingen wie LDAP-Kennwörtern verwendet.

Als Teil dieser Arbeit wollten wir sicherstellen, dass selbst privilegierte Benutzer, die diese Werte lesen können, sie nicht versehentlich verfügbar machen, indem sie den Status eines Dienstes exportieren oder ein Archiv des SMF-Repositorys erstellen. Daher habe ich den Export- und Archivierungsbefehlen in svccfg das Flag '-a' hinzugefügt, das alle Eigenschaftswerte explizit exportiert, und die Standardeinstellung geändert, um alle schreibgeschützten auszuschließen.

Leider wird diese Einschränkung nicht korrekt angewendet. In diesem Fall lehnen wir es einfach ab, nur einige ausgewählte Eigenschaften in der Eigenschaftsgruppe "Allgemein" mit Werten zu exportieren. Der Rest wird ohne Werte exportiert, was Sie sehen. Und leider hilft die Verwendung der Option -a hier nicht weiter, da wir zum Zeitpunkt des Erreichens des relevanten Punkts nicht mehr über den erforderlichen Kontext verfügen, um zu wissen, dass Sie dies bestanden haben. Es ist sogar fair zu hinterfragen, ob dieses Flag erforderlich sein sollte, um diese Werte verfügbar zu machen: Die Identität der Berechtigungen, die das Ändern des Dienststatus ermöglichen, ist in der Tat vertraulich und für einen Angreifer nützlich. Zweifellos dachte ich daran, als ich das schrieb, und es ist vernünftig, dies aus der Sicht anderer einzuschränken, es sei denn, es ist ausdrücklich erwünscht. Aber in früheren Versionen von S10, exportiertes XML und Archive enthielten es, so dass es definitiv eine inkompatible Änderung war. Es wäre dir verziehen, wenn du darüber verärgert wärst. Das eigentliche Problem hierbei ist jedoch, dass -a nicht funktioniert, wenn die betreffende Eigenschaftsgruppe "allgemein" ist. Wie du die erste Person bist, die das trifft, weiß ich nicht.

Sie können dieses Problem auf seiner Seite hier verfolgen . In der Zwischenzeit können Sie das Problem umgehen, indem Sie die Werte der Eigenschaften manuell in das generierte XML einfügen. Beachten Sie, dass Sie sie bei Bedarf auch über svcprop (1) lesen können. Sie haben meine Entschuldigung. Vielen Dank an Deirdre Straughan, der mich auf diese Frage aufmerksam gemacht hat.