illumos gate

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.

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='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?

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.

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 http://www.intisari-online.com/listinfo.php?pid=1293