Why is SMF manifest losing configuration data when exported on SmartOS?

Question

I'm running a server process under SMF (Server Management Facility) on Joyent's Base64 1.8.1 SmartOS image.

For those not aqauinted with SmartOS, it is a cloud-based distribution of IllumOS with KVM. But essentially it is like Solaris and inherits from OpenSolaris. So even if you've not used SmartOS, I'm hoping to tap into some Solaris knowledge on ServerFault.

My issue is that I want an unprivileged user to be allowed to restart a service that they own. I have worked out how to do that by using RBAC and adding an authorisation to /etc/security/auth_attr and associating that authorisation with my user.

I then added the following to my SMF manifest for the 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>

And this works well when imported. My unprivileged user is allowed to restart, start and stop its own server process (this is for automated code deployments).

However, if I export the SMF manifest, this configuration data is gone... all I see in that section is this:

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

Does anybody know why this is happening? Is my syntax wrong, or am I simply using SMF incorrectly?

Answer 1

Because svccfg(1M) is broken, and I broke it.

Back in 2007, I added a feature to SMF that allowed for property groups that could contain sensitive information, readable only by users with appropriate privileges. The idea was that you could add a "read_authorization" property to a property group, and anyone who was neither privileged (basically, root) nor in possession of one of the authorizations named by that property would be unable to read the values of any property in the group. This was integrated under this commit, and is used by (at least) the Sun ZFS storage products to store things like LDAP passwords.

As part of that work, we wanted to make sure that even privileged users who could read these values would not accidentally expose them by exporting a service's state or creating an archive of the SMF repository. So I added the '-a' flag to the export and archive commands in svccfg that would explicitly export all property values, and changed the default to exclude any that were read-protected.

Unfortunately, this restriction is not being applied correctly; in this case, we simply refuse to export any but a select few properties in the "general" property group with values. The rest are exported without any values, which is what you're seeing. And unfortunately, using the -a option won't help here, because by the time we reach the relevant point, we no longer have the context required to know that you've passed that. It's even fair to question whether this flag should be required to expose these values: the identity of the authorizations that allow changing the service state is indeed sensitive, and would be useful to an attacker. No doubt that was in my mind when I wrote this, and it's reasonable to restrict that from others' view unless it's explicitly desired. But in prior versions of S10, exported XML and archives contained it, so it was definitely an incompatible change. You'd be forgiven for being upset about that. But the real problem here is that -a doesn't work when the property group in question is "general". How you're the first person to hit this I have no idea.

You can follow this issue at its page, here. In the meantime, you can consider working around it by manually adding the properties' values in the generated XML. Note that you can also read them via svcprop(1) if needed. You have my apologies. Thanks to Deirdre Straughan for bringing this question to my attention.