Change role creation so caller cannot create roles with more permission than himself

[billkalter]

What is the Issue?

This issue is in the larger context of creating a system where Emo can have delegated API key management. Today Emo is best administered by a single cabal of administrators who create roles and API keys at the client's request. As Emo expands there will be a need to delegate role and API key management. That is, if the admin has a trusted client who should be able to create API keys and give a discrete set of permissions to those keys there should be a safely delegated way to do so. For example:

• Admin grants Project X's administrator, xadmin, full permissions on all tables in the project_x:app placement: sor|*|if(intrinsic("~placement":"project_x:app"))
• xadmin wants to create roles and API keys further restricting tables by project. For example, he may want to create a role and API key for project "runway" with permission sor|*|if(and(intrinsic("~placement":"project_x:app")),{..,"project":"runway"}))

For this to work admin needs to be sure that xadmin cannot create roles outside of the scope of his authority. For example, xadmin should not be able to create a role with permissions such as sor|*|if(intrinsic("~placement":"restricted:app")) because xadmin himself does not have that permission.

Note that this is note a complete solution in itself as it still leaves open many holes such as restricting which roles a delegated API key can update and which API keys the delegate can modify, but it is a crucial piece of the overall puzzle for distributed API key management.

How to Test and Verify

1. Check out the project
2. Create a role with limited permissions, such as sor|read|* and including system|manage_api_keys and system|manage_roles and assign it to a new API key.
3. Using the API key create a role with permission sor|*

With the current Emo this role creation is allowed. With the update in place the role creation should fail with a message that the user does not have permission to grant sor|*.

Risk

The risk is mitigated so long as all API keys and roles are maintained by admins only. However, the point of this issue is undoing that restriction. For that reason, the risk is low if operations remain at status quo, but high as soon as delegation is put into practice.

Level

High. The level of changes to ensure one unbounded permission, such as sor|if(in("read","update"))|if(intrinsic("~table":not(like("*:sys")))) is wholly contained within a users other permissions is a non-trivial exercise.

Issue Checklist

• Make sure to label the issue.

• Well documented description of use-cases and bugs.