Tony Nguyen writes: > 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 > _______________________________________________ > smf-discuss mailing list > smf-discuss at opensolaris.org
The idea of making smf.modify a superset of smf.manage makes sense to me. smf.modify allows the user to add, delete, or modify services, etc. If you can add or delete a service, it seems logical that you should also be allowed to enable it. tom
