Description
Thrift interface between sentry server and hdfs sentry client should be updated to send privileges granted to users.
Attachments
Attachments
- SENTRY-2170.001.patch
- 105 kB
- Krishna Kalyan
- SENTRY-2170.002.patch
- 62 kB
- Krishna Kalyan
- SENTRY-2170.003.patch
- 63 kB
- Krishna Kalyan
- SENTRY-2170.003.patch
- 63 kB
- Krishna Kalyan
Issue Links
- links to
Activity
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12915785/SENTRY-2170.001.patch against master.
Overall: +1 all checks pass
SUCCESS: all tests passed
Console output: https://builds.apache.org/job/PreCommit-SENTRY-Build/3710/console
This message is automatically generated.
Here is the proposal
Currently TPrivilegeChanges is created to hold all the privileges that are granted to an object.
Case-1: When a snapshot is taken.
All the privileges granted to a object are added to addPrivileges.
Case-2: When a new privileges is granted
New privileges granted it added to addPrivileges
Case-3: When a privileges is revoked
Privileges that is revoked is added to delPrivileges
Both addPrivileges/delPrivileges have role to permission mapping. We could extend this mapping to send user permissions as well.
New Definitions
enum TPrivilegeEntityType { ROLE, USER, OBJECT } struct TPrivilegeEntity { # Type of the privilege entity 1: required TPrivilegeEntityType type; # Value of entity 2: required string value; }
struct TPrivilegeChanges {
- The authorizable object that needs to be updated.
1: required string authzObj;
- The privileges that needs to be added to
- the authorizable object.
2: required map<TPrivilegeEntity, string> addPrivileges;
- The privileges that needs to be deleted to
- the authorizable object.
3: required map<TPrivilegeEntity, string> delPrivileges;
}
why does " TPrivilegeEntityType { ROLE, USER, OBJECT }" include "Object"? If it is for future use, we can add it in the future.
LinaAtAustin it's not for future purpose. we need it currently.
we handle rename bit differently when there isa privilege that is renamed, TPrivilegeChanges is updated differently.
- authzObj will be initialized with a constant string "_RENAME_PRIV_"
- addPrivileges will have (newAuthz, newAuthz)
- delPrivileges will have (oldAuthz, oldAuthz)
This can be done in a better way. I will update this in different commit.
In short to your question, we need that to handle renaming of privileges.
spena and LinaAtAustin
(Full Snapshot) PermissionsUpdate -> TPermissionsUpdate -> Collection<TPrivilegeChanges> (Del Update) List<PermissionsUpdate> -> PermissionsUpdate -> TPermissionsUpdate -> TPrivilegeChanges One instance of TPrivilegeChanges has the permission information about a HMS object 1. Retrieving full/Delta snapshot from persistent store. Construct 1. (Full Snapshot)PermissionsImage 1. Role Image 2. Object ->Role,permission mapping 3. Create thrift version to send stover to NN pug-in 1. PermissionsUpdate 1. TPermissionsUpdate is updated with permissions and role information from PermissionsImage 1. TPrivilegeChanges (one instance per HMS object) 2. TRoleChanges(one Entry for each role which has role -> group Mapping) 2. Retrieving Delta Update from persistent store. 1. deltaRetriever#retrieveDelta 2. Get all the PermissionsUpdate entries from MSentryPermChange table 1. Each PermissionsUpdate object corresponds to one permission change.
kkalyan I agree with your design. The only thing to change is for TPrivilegeEntityType. Instead of
{ ROLE, USER, OBJECT }, how about
{ ROLE, USER, AUTHZ_OBJECT }or something that is more specific than OBJECT?
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12920887/SENTRY-2170.002.patch against master.
Overall: +1 all checks pass
SUCCESS: all tests passed
Console output: https://builds.apache.org/job/PreCommit-SENTRY-Build/3746/console
This message is automatically generated.
Do we need to preserve on the wire compatibility between old protocol and the new one?
akolb I don't see a reason to maintain that compatibility unless sentry supports the use of different version of of sentry jars in client and server side. I'm not sure if it's valid use case.
The next version of Sentry will be 2.1.0, so being a minor version, I think we should think of compatibility when making changes on the API.
spena I understand that. Compatibility should be maintained while changing the API's that are exposed for other components to use. This is not the case now. Changing the thrift definitions does not effect the sentry client API's that are exposed to other components.
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12921623/SENTRY-2170.003.patch against master.
Overall: -1 due to 2 errors
ERROR: mvn test exited 1
ERROR: Failed: org.apache.sentry.tests.e2e.dbprovider.TestDbPrivilegeCleanupOnDrop
Console output: https://builds.apache.org/job/PreCommit-SENTRY-Build/3757/console
This message is automatically generated.
See test failure. Test failure looks un-related. Will resubmit the patch again.
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12922117/SENTRY-2170.003.patch against master.
Overall: +1 all checks pass
SUCCESS: all tests passed
Console output: https://builds.apache.org/job/PreCommit-SENTRY-Build/3766/console
This message is automatically generated.
This include making changes to TPrivilegeChanges class.
enum TPrivilegeEntityType
{ ROLE, USER, OBJECT }New Definitions
Here is the an initial thought on changes to TPrivilegeChanges.
struct TPrivilegeChanges {
1: required string authzObj;
2: required map<TPrivilegeEntity, string> addPrivileges;
3: required map<TPrivilegeEntity, string> delPrivileges;
}