[DISCUSS] Changing role <-> priv relationship from M:N to 1:N

[Alexander Kolbasov <ak...@cloudera.com>]

Hello,

I would like to start a discussion about the relationship model between
roles and permissions in Sentry. Currently it uses N:M model where a single
permission may belong to multiple roles and a single role can have multiple
permissions.

Given that all permission manipulations are always happening in the context
of a specific role I would suggest changing that to 1:N model where a role
contains a set of permissions, but any permission only belongs to a single
role. I think that this is a simpler model both conceptually and in terms
of implementation. The downside is that we may have multiple "duplicate"
permissions (same permissions for the same objects) within multiple roles,
but I don't see any problem with this.

What do other folks think about this?

- Alex

Re: [DISCUSS] Changing role <-> priv relationship from M:N to 1:N

[Alexander Kolbasov <ak...@cloudera.com>]

> 
> On Wed, Nov 9, 2016 at 2:11 PM, Alexander Kolbasov <ak...@cloudera.com>
> wrote:
> 
>> Hello,
>> 
>> I would like to start a discussion about the relationship model between
>> roles and permissions in Sentry. Currently it uses N:M model where a single
>> permission may belong to multiple roles and a single role can have multiple
>> permissions.
>> 
>> Given that all permission manipulations are always happening in the context
>> of a specific role
> 
> The only exception to this is implicit permission changes:
> - Drop/rename table triggers changes in the permissions and hence there is
> no role context.

There is no explicit role context but we can assume implicit role context - we need to find permissions for the affected object and remove them from their respective roles.


> 
> 
>> I would suggest changing that to 1:N model where a role
>> contains a set of permissions, but any permission only belongs to a single
>> role. I think that this is a simpler model both conceptually and in terms
>> of implementation. The downside is that we may have multiple "duplicate"
>> permissions (same permissions for the same objects) within multiple roles,
>> but I don't see any problem with this.
> 
> Some minor downsides I see are:
> 1. Space. Would be good to estimate the ball park of how much extra space
> this might need in real deployments, which is a function of how many roles
> point to the same permission in real world. To me this seems negligible,
> but would be good to confirm.

Do we have any way to estimate how many shared permissions are in real-world installations?

> 2. As mentioned above, how do we handle implicit permission changes? If we
> look for the permission in all roles, it might be slow, Would that be
> acceptable?

We still have a table with all permissions, so we can easily query for all permissions matching the object to be deleted. As long as we keep a back-reference from a permission to its enclosing role it should be Ok performance-wise.

> I am curious, apart from simplicity what other value is this bringing?

A closer match with the way these relate to each other. And this will eliminate the need for the special “cleanup thread” in SentryStore that takes care of orphaned permissions.

- Sasha

> 
> What do other folks think about this?
>> 
>> - Alex
>> 
> 
> 
> 
> -- 
> Sravya Tirukkovalur

Re: [DISCUSS] Changing role <-> priv relationship from M:N to 1:N

[Sravya Tirukkovalur <sr...@cloudera.com>]

Hi Sasha,

On Wed, Nov 9, 2016 at 2:11 PM, Alexander Kolbasov <ak...@cloudera.com>
wrote:

> Hello,
>
> I would like to start a discussion about the relationship model between
> roles and permissions in Sentry. Currently it uses N:M model where a single
> permission may belong to multiple roles and a single role can have multiple
> permissions.
>
> Given that all permission manipulations are always happening in the context
> of a specific role

The only exception to this is implicit permission changes:
- Drop/rename table triggers changes in the permissions and hence there is
no role context.


> I would suggest changing that to 1:N model where a role
> contains a set of permissions, but any permission only belongs to a single
> role. I think that this is a simpler model both conceptually and in terms
> of implementation. The downside is that we may have multiple "duplicate"
> permissions (same permissions for the same objects) within multiple roles,
> but I don't see any problem with this.

Some minor downsides I see are:
1. Space. Would be good to estimate the ball park of how much extra space
this might need in real deployments, which is a function of how many roles
point to the same permission in real world. To me this seems negligible,
but would be good to confirm.
2. As mentioned above, how do we handle implicit permission changes? If we
look for the permission in all roles, it might be slow, Would that be
acceptable?

I am curious, apart from simplicity what other value is this bringing?

What do other folks think about this?
>
> - Alex
>



-- 
Sravya Tirukkovalur