A quick poll here to get input from folks. The background for this is in 6834760 svcadm shouldn't assert() when not enough privileges
In summary, since the integration of 6762307, user needs both solaris.smf.modify and solaris.smf.manage to run svcadm enable/disable which is a regression to the policy in smf_security(5). In the evaluation of 6834760, I listed a couple possible solutions. A chat with Liane convinced me the most reasonable solution is to expand the privilege for solaris.smf.modify, making it a superset of solaris.smf.manage. In other words, users with solaris.smf.modify will be able to perform service actions granted to solaris.smf.manage (e.g. refresh/restart/clear/mark). At the moment, the differences between privileges granted to the mentioned authorizations are blurry and perhaps inconsistent: - Currently, users with smf.modify can fake restart and clear actions by disabling then enabling services. - solaris.smf.modify also allows service/instance/property modifications but doesn't allow service refresh. So users with smf.modify authorization cannot fully modify configurations. Making solaris.smf.modify to have privileges granted to solaris.smf.manage allows users to properly perform restart/clear actions and correctly make changes to configuration. The proposed solution also implied allowing users with solaris.smf.modify authorization to do svcadm mark. Feedback/comments are appreciated before I start looking at configd code. cheers, -tony
