Adar Dembo has posted comments on this change. ( http://gerrit.cloudera.org:8080/12500 )
Change subject: [sentry] add privilege scope validation to SentryAuthzProvider ...................................................................... Patch Set 4: (4 comments) http://gerrit.cloudera.org:8080/#/c/12500/4//COMMIT_MSG Commit Message: http://gerrit.cloudera.org:8080/#/c/12500/4//COMMIT_MSG@9 PS4, Line 9: base based http://gerrit.cloudera.org:8080/#/c/12500/4//COMMIT_MSG@16 PS4, Line 16: 3. grant option from the former implies the grant option from the latter. What are these, and how do they fit into the overall Sentry authorization model? I'm using https://docs.google.com/document/d/1SEBtgWwBFqij5CuCZwhOqDNSDVViC0WERq6RzsPCWjQ/edit#heading=h.p3aqzzmumh8m as a guide and it only talks about authorizables and actions. http://gerrit.cloudera.org:8080/#/c/12500/4//COMMIT_MSG@36 PS4, Line 36: This patch adds privilege scope validation to SentryAuthzProvider to : ensure only authorizable with a higher scope on the hierarchy can imply : authorizables with a lower scope on the hierarchy. I don't claim to understand this problem well, but here's my mental model of the situation. Implication works on two axes: authorizables, and actions. There's even a third axis if you include grant options, though I don't understand them well enough to know whether they affect the authorization hierarchy. Surprisingly (to me at least), Kudu actually has two different authz use cases: DDLs, and authz token creation. They're different in that each one needs a slightly different set of privileges from Sentry: DDLs When authorizing a DDL, Kudu needs to know whether a user has enough privileges to perform a single logical action. Examples include "CREATE TABLE db.foo", or "ALTER TABLE db.foo RENAME TO db.bar". In every case, the DDL is permitted if there exists a Sentry privilege that directly maps to the action+authorizable. It is also permitted if there exist Sentry privileges that imply the action+authorizable. For example, if I am trying to do "CREATE TABLE db.foo" and I don't have "CREATE ON DATABASE db" but I do have "CREATE ON SERVER server1" (or I have "ALL ON DATABASE db"), then I'm allowed to create this table. Authz token creation When creating an authz token for a user, Kudu needs _all of the privileges that may affect the user's interaction with a table_. This is subtly different than the DDL case, because although it includes the direct mapping case as well as the "implication from higher up in the action or authorizable hierarchies" case, it also includes a third case: discrete privileges on actions/authorizables that lie _below_ in the implication hierarchy. For example, suppose I request an authz token on db.foo and the only privileges matching my name are "METADATA ON db.foo" and "SELECT ON COLUMN db.foo.col1". This is enough to build an authz token that allows me to scan "col1" out of "db.foo", but not enough to do any kind of destructive DDL on the table. Why do these distinctions matter? Because they map to slightly different requests from Sentry: 1. In English, the DDL case maps to "tell me (yes/no) whether user U may perform action AC against authorizable AU, and please factor in any privileges that may exist in the higher levels of the various implication hierarchies to inform the decision." 2. The authz token creation case maps to "give me all of the privileges for user U that affect authorizable AU (where AU is some table). This includes privileges derived via implication from both above and below in the implication hierarchies." It sounds like list_sentry_privileges_by_user_and_itsgroups corresponds to #2 from above, and this patch implements some client-side logic to map the results into #1. Why can't we directly implement #1 as a new query API in Sentry? You make the case against that below but I don't understand it; I don't see how wildcard authorizables factor into the discussion. http://gerrit.cloudera.org:8080/#/c/12500/4//COMMIT_MSG@40 PS4, Line 40: filering filtering Below too -- To view, visit http://gerrit.cloudera.org:8080/12500 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-Project: kudu Gerrit-Branch: master Gerrit-MessageType: comment Gerrit-Change-Id: I89437a04a4fa18e501d21c3abf5d66a2d22ce58a Gerrit-Change-Number: 12500 Gerrit-PatchSet: 4 Gerrit-Owner: Hao Hao <[email protected]> Gerrit-Reviewer: Adar Dembo <[email protected]> Gerrit-Reviewer: Alexey Serbin <[email protected]> Gerrit-Reviewer: Andrew Wong <[email protected]> Gerrit-Reviewer: Hao Hao <[email protected]> Gerrit-Reviewer: Kudu Jenkins (120) Gerrit-Comment-Date: Tue, 05 Mar 2019 20:18:19 +0000 Gerrit-HasComments: Yes
