Define roles for IPM

[isc-tleavitt]

We need to give IPM to be able to manage roles granting relevant SQL permissions for IPM actions (which are particularly messy otherwise). There should be a separate API to grant all relevant SQL permissions to a given existing user/role.

This needs more investigation/specification, but my gut feeling is that there should be two roles: %IPM_Read to grant relevant SQL privileges for read operations via IPM (possibly) %IPM_Write to grant relevant SQL privileges for any inserts/updates (not sure of the extent to which we use these - most of IPM operates through objects)

We'll want zpm "enable" to manage these roles across different namespaces, provided the roles exist. We may also want to define resources with the same / related names.

[isc-dchui]

Some general thoughts from today's meeting: The goal is to tighten security so users of IPM will not need %ALL to install modules or see which ones are installed. This entails two roles:

1. %IPM_Install—be able to (un)install modules, configure repositories, etc.
2. %IPM_List—be able to see what modules are installed

We should be able to use privileged routine applications to temporarily escalate roles to perform extra work if necessary. For example, if an IPM package creates a web application, the user driving it may only have something akin to %Developer, but will need %Admin_Secure to create the web app. If a privileged routine application is setup, it will allow the %IPM package to temporarily escalate the user's role to create the web app. Since this privilege only exists for the %IPM package, it prevents the user from creating their own custom code to "hack" IRIS and grant themselves more privileges.

It would also be nice to be able to lock down a system such that no users have direct code editing privileges, but can use IPM to install/update packages. This combined with signed packages and a history log would provide helpful security and auditability.