Tom Whitten wrote: > 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? > Sorry, I wasn't clear. A user with smf.modify is supposed to be able to enable/disable services. The fix for 6834760 made all svcadm subcommands modify properties in restarter_actions property group. Changes to restarter_actions pg requires smf.manage authorization thus user with only smf.modify no longer can disable/enable services. The proposed solution will allow user with smf.modify to make changes to restarter_actions pg and effective has all privileges granted to smf.manage.
-tony
