smf(5): authorizations built-in
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.
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.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.