Bug #3315

svccfg export -a drops values in PG "general"

Added by Keith Wesolowski over 7 years ago. Updated over 6 years ago.

cmd - userland programs
Start date:
Due date:
% Done:


Estimated time:
Gerrit CR:


When exporting a service with valued properties in the "general" property group, svccfg(1M) exports these properties as if they had no values, even when they do and even when the -a option is given. See


3315.tst.tar.gz (2.06 KB) 3315.tst.tar.gz Keith Wesolowski, 2012-12-21 12:25 AM



Updated by Keith Wesolowski over 7 years ago

According to smf_security(5), svccfg(1M), and the PSARC/2007/177 case materials, the correct behaviour is that property groups other than those of type application should be unaffected by the presence of read_authorization. That is, these property groups should have their properties exported with all values by the export and archive commands, regardless of whether the -a option is provided. This will allow someone who can obtain such an archive to learn the authorizations required to modify property values, if any. Note that an unprivileged user can already do so via svcprop(1). The fix for this bug will match the documented behaviour.


Updated by Keith Wesolowski over 7 years ago

The attached tarball contains a set of tests that were used to guard against some potential regressions as well as to clearly show that the bug is fixed. To run it, simply set the environment variable ROOT to either empty (use the system's svccfg) or the location of a proto area whose svccfg is to be tested. The test must be run as root in order to create and delete services, so run it in a zone.

The simplest possible demonstration of the bug is as follows. First, import the trivial service defined svc2.xml. Then note that the property value in the 'general' property group is not contained in the XML output from either 'svccfg export svc2' or 'svccfg export -a svc2'. This is doubly a problem: first because read_authorization doesn't apply to property groups of type 'framework', second because there isn't even a read_authorization property in that group. Similar problems exist with respect to other reserved property group types.

There are several other test cases in the tarball that are worth mentioning, as they test specific aspects of SMF's behaviour when exporting sensitive property groups (those with a read_authorization property).

The existence of svc3 allows us to verify that one cannot export the values of sensitive properties in one service by introducing another service referencing the first service as a dependent. Recall that SMF creates a property group in the dependent service of type dependency/framework with the same name as the dependent declaration in the dependency service. If a property group with this name already exists, the new service cannot be imported. However, if the victim service's property group were to be later deleted and replaced with a sensitive property group of type application, we must be sure that the property values in that service are not inadvertently exposed when the attack service is exported. The correct behaviour here is simply to export the dependent property group in the attack service with its own values as an ordinary property group, since the dependency relationship was broken by the deletion and replacement of the victim service's property group. Note that a similar attack might consist of simply creating an attack service with no dependents, then later adding a dependent/framework property group with appropriate properties. The effect is the same, as is the correct result.

Another test creates the read_authorization property in a service's application property group, then creates an identical property group with valued properties in an instance of that service. In this case, the protection afforded by the read_authorization property must be preserved by composition; that is, the instance's properties must not be exported by default.

None of this applies when the -a option is provided. This flag should have no effect whatsoever on property values in property groups of types other than application or user-defined types. However, in those property groups, it should cause all values to be exported even if the property group is sensitive (provided of course that the user has sufficient privileges to do so).

In time, perhaps this simple set of tests can be expanded to cover a more exhaustive set of cases.


Updated by Keith Wesolowski over 7 years ago

The original complete text of the bug report is as follows, copied here in case the source material later becomes unavailable:

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='' />
  <!-- Allow to be started and stopped -->
  <propval name='value_authorization' type='astring'
    value='' />
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'/>
Does anybody know why this is happening? Is my syntax wrong, or am I simply using SMF incorrectly?

Updated by Keith Wesolowski over 7 years ago

And my original evaluation (which should be considered historical; the commentary in this bug represents thinking refined by research):

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.

Updated by Rich Lowe over 7 years ago

  • Status changed from New to Resolved
  • % Done changed from 0 to 100
  • Tags deleted (needs-triage)

Resolved in 24ed8e4


Updated by Anonymous over 6 years ago

The longchamp handbags outlet tributes to Longchamps heritage by harkening back to past collections. The leather-based is utilized in the smoothest and the majority of all-natural form with a light-weight patina outcome as well as in comfortable shades, to present a retro look for the the latest models of. A restrained, easy and stylish|stylish, easy and restrained|easy, restrained and stylish|easy, restrained and stylish|stylish, restrained and easy|easy, restrained and stylish}-to-put on collection for elegant girls.This season, learn an extra-functional tote as well as a tiny messenger bag in the new mocha colorway.
Ray Ban Aviators Uv Protection

Also available in: Atom PDF