Tony Nguyen writes: > Tom Whitten wrote: > > 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, > > User with smf.modify actually can enable/disable services today. Indeed, > it's logical that user who can modify, enable, disable and clear and > restart through workarounds, be able to perform those actions through > official svcadm subcommands. > > -tony
I guess I'm a little slow today. If a user with smf.modify can enable/disable services, why is it necessary to make smf.modify a superset of smf.manage? tom
