Learning Solaris 10 Check out the Zones F.A.Q. !

Let’s find out how to take advantage of RBAC authorizations for service management.

Infodoc 80115 provides an example of such configuration but not very detailed and anyway, now that you need a support contract to access it…

The NFS server has been configured by root and is currently running. I want user “bob” to be able to manage it.

1. Edit the “/etc/security/auth_attr” file to add the special authorization that “bob” will use to manage the NFS server. Add the line :

solaris.smf.manage.nfs/server:::NFS Server management::

2. Add that authorization to bob’s list :

#usermod -A solaris.smf.manage.nfs/server bob

At that point, RBAC’s configuration is over but SMF is not yet aware of anything. This is probably the first surprising finding. Appending the service name to the preexisting solaris.smf.manage is as far as I know purely some naming best practice. What I mean is that SMF by default only recognizes general authorizations like solaris.smf.manage or solaris.smf.modify.application. Anything more specific will have to be configured manually into the SMF repository.

3. Modify the configuration of the NFS server service_fmri using the “general/action_authorization” property. The smf_security manpage says that “general/action_authorization property can specify additional authorizations that permit service actions to be requested for that service instance.”
So if you don’t want to give bob the authorization to manage all services using solaris.smf.manage, you need to specify the specific one that grants Bob the right to manage the NFS Server.

#svcprop -p general nfs/server
general/enabled boolean true
general/entity_stability astring Stable
general/single_instance boolean true

#svccfg -s nfs/server setprop general/action_authorization=astring: ’solaris.smf.manage.nfs/server’

Don’t forget to make the change active :

#svcadm refresh nfs/server

And check the result :

#svcprop -p general nfs/server
general/enabled boolean true
general/entity_stability astring Stable
general/single_instance boolean true
general/action_authorization astring solaris.smf.manage.nfs/server

4. Let’s see what Bob can do now :

#su - bob
(bob)$ svcs nfs/server
STATE STIME FMRI
online 11:02:17 svc:/network/nfs/server:default

(bob)$ /usr/sbin/svcadm restart nfs/server
(bob)$ /usr/sbin/svcadm mark maintenance nfs/server
(bob)$ svcs -pv nfs/server
STATE NSTATE STIME CTID FMRI
maintenance - 11:00:53 - svc:/network/nfs/server:default

(bob)$ /usr/sbin/svcadm clear nfs/server
(bob)$ svcs nfs/server
STATE STIME FMRI
online 10:57:04 svc:/network/nfs/server:default
(bob)$ /usr/sbin/svcadm refresh nfs/server

A look at the nfs/server logfile shows :

(bob)$ cat /var/svc/log/network-nfs-server:default.log
(—) the restart :
[ Apr 25 10:57:46 Executing stop method (”/lib/svc/method/nfs-server stop 133″) ]
[ Apr 25 10:57:46 Method “stop” exited with status 0 ]
[ Apr 25 10:57:46 Executing start method (”/lib/svc/method/nfs-server start”) ]
[ Apr 25 10:57:49 Method “start” exited with status 0 ]
[ Apr 25 10:57:49 Rereading configuration. ]
[ Apr 25 10:57:49 No ‘refresh’ method defined. Treating as :true. ]
(—) the ‘mark’
[ Apr 25 11:00:52 Stopping for maintenance due to administrative_request. ]
[ Apr 25 11:00:52 Executing stop method (”/lib/svc/method/nfs-server stop 161″) ]
[ Apr 25 11:00:53 Method “stop” exited with status 0 ]
[ Apr 25 11:00:53 Stopping for maintenance due to administrative_request. ]
(—) the ‘clear’
[ Apr 25 11:02:14 Leaving maintenance because clear requested. ]
[ Apr 25 11:02:14 Enabled. ]
[ Apr 25 11:02:14 Executing start method (”/lib/svc/method/nfs-server start”) ]
[ Apr 25 11:02:17 Method “start” exited with status 0 ]
[ Apr 25 11:02:17 Rereading configuration. ]
[ Apr 25 11:02:17 No ‘refresh’ method defined. Treating as :true. ]
[ Apr 25 11:02:17 Rereading configuration. ]
(—) the ‘refresh’
[ Apr 25 11:03:17 Rereading configuration. ]
[ Apr 25 11:03:17 No ‘refresh’ method defined. Treating as :true. ]

What about actions he cannot perform :

(bob)$ /usr/sbin/svcadm disable nfs/server
svcadm: svc:/network/nfs/server:default: Permission denied.

(bob)$ /usr/sbin/svcadm enable nfs/server
svcadm: svc:/network/nfs/server:default: Permission denied.

Why is that so ? Because the svcadm subcommands ‘restart’, ‘refresh’, ‘mark’ & ‘clear’ do NOT modify any property in the SMF persistent repository. It only affects the state of the service. In other words, when Bob uses them, the service always stays “enabled” as specified by the ‘enabled’ property of the ‘general’ property group.

#svcprop -p general/enabled nfs/server
general/enabled boolean true

But when one uses the ‘disable’ action, the value of that property switches to ‘false’. The repository is changed. You need another change to the configuration so that Bob may do that.

5. Allow Bob to disable/enable the service.

The value_authorization is a property that can be added to any property group. It allows changing the values of any property of that property group except modify_authorization. ( Same manpage )
So to be able to change the value of the property ‘general/enabled’ of the NFS server, we have to add the value_authorization property to the ‘general’ property group and assign Bob’s authorization to it :

# svccfg -s nfs/server setprop general/value_authorization=astring: ’solaris.smf.manage.nfs/server’
# svcadm refresh nfs/server
# svcprop -p general nfs/server
general/enabled boolean true
general/entity_stability astring Stable
general/single_instance boolean true
general/action_authorization astring solaris.smf.manage.nfs/server
general/value_authorization astring solaris.smf.manage.nfs/server

# su - bob

(bob)$ /usr/sbin/svcadm disable nfs/server
(bob)$ svcs -x nfs/server
svc:/network/nfs/server:default (NFS server)
State: disabled since Mon Apr 25 11:06:30 2005
Reason: Disabled by an administrator.
See: http://sun.com/msg/SMF-8000-05
See: nfsd(1M)
See: /var/svc/log/network-nfs-server:default.log
Impact: This service is not running.

(bob)$ /usr/sbin/svcadm enable nfs/server
(bob)$

6. Comments :

• The logfile doesn’t keep track of who did what. The identity of the user who disabled the service can’t be established.
• Documentation always refers to the authorization solaris.smf.manage.service_fmri when referring to RBAC. However, this is not mandatory. One can create an authorization solaris.bob in the RBAC auth_attr file, assign it to user bob and specify solaris.bob as the extra authorization in the SMF repository :
  # svcprop -p general nfs/server
  general/enabled boolean true
  general/entity_stability astring Stable
  general/single_instance boolean true
  general/action_authorization astring solaris.bob
  general/value_authorization astring solaris.bob

  Everything works in the exact same way.

• Going further with solaris.bob, one could think of setting up a special set of authorizations in the SMF repository rather than in RBAC, assigning the ‘general/action_authorization’ and ‘general/value_authorization’ to solaris.bob for several services. We end up being able to modify the list of Bob’s capabilities using svccfg rather than the RBAC utilities.