smf(5): authorizations built-in

| Stephen | Product.

I mentioned yesterday that you can manipulate services if you have the appropriate authorizations, without needing to possess any privileges. For instance, my current shell has the following privileges and authorizations:

$ ppriv $$
117292: bash
flags = <none>
E: basic
I: basic
P: basic
L: all
$ auths
solaris.device.cdrw,solaris.profmgr.read,solaris.jobs.users,solaris.mail.mailq

And if we try to manipulate a service managed by smf(5) with this set of authorizations, we’ll get a predictable result.

$ svcadm restart network/smtp
svcadm: network/smtp: Permission denied.

However, smf(5) defines two big authorizations:

  • solaris.smf.manage, which allows the user to request a restart, refresh, or other state modification of any service instance, and
  • solaris.smf.modify, which allows the users to create or delete services and instances, as well as manipulate any of their property groups or properties.

(There are also lesser built-in authorizations—solaris.smf.modify.method, solaris.smf.modify.dependency, solaris.smf.modify.application, and solaris.smf.modify.framework—which allow the manipulation of properties within property groups of the mentioned type. And you can also customize the authorizations to allow an action at the instance level and to manipulate properties at the property group level.)

To make assigning batches of authorizations scale, the role-based access control facility (RBAC) allows the definition of rights profiles. (The definitions are contained in /etc/security/prof_attr, and the documentation is prof_attr(4).) The service management facility delives with two rights profiles we think are convenient:

$ grep ^Service /etc/security/prof_attr
Service Management:::Manage services:auths=solaris.smf.manage,solaris.smf.modify
Service Operator:::Administer services:auths=solaris.smf.manage,solaris.smf.modify.framework

We can then add the user_attr(4) database to connect a user with the appropriate profile, like:

$ grep sch /etc/user_attr
sch::::profiles=Service Management

(You can edit /etc/user_attr by hand or, if your password database is local, using the -P option to useradd(1M). The equivalent configuration via direct authorizations would read

$ grep sch /etc/user_attr
sch::::auths=solaris.smf.manage,solaris.smf.modify

and will work fine except that if the Service Management profile were to be enhanced subsequently, a user or role with the old explicity authorizations might not have the correct set for future operations.)

So now our authorization list is expanded, but our privileges are unchanged:

$ auths
solaris.smf.manage,solaris.smf.modify,solaris.device.cdrw,solaris.profmgr.read,solaris.jobs.users,solaris.mail.mailq
$ ppriv $$
117292: bash
flags = <none>
E: basic
I: basic
P: basic
L: all

and we can carry out our operation from an authorized, but unprivileged user account:

$ svcs network/smtp
STATE          STIME    FMRI
online         Sep_21   svc:/network/smtp:sendmail
$ svcadm restart network/smtp
$ svcs network/smtp
STATE          STIME    FMRI
online         23:58:21 svc:/network/smtp:sendmail

And, finally, since the user_attr(4) database has network name service backends, you can actually make authorization grants that apply across an administrative domain, whether you’re giving out the big authorizations illustrated here or custom authorizations specific to a set of services running at your site.