Colm, Glad you find the cause!
You can revert Sentry-1291, and see if it works. If so, it is issue at finding cached privileges. Cheers, Lina Sent from my iPhone > On Dec 13, 2017, at 4:58 AM, Colm O hEigeartaigh <cohei...@apache.org> wrote: > > Hi, > > I can see what the problem is (that the authorization hierarchy does not > contain the column, and hence doesn't match against the cached privilege), > but I'm not sure about the best way to solve it. Either the way we are > creating the authorization hierarchy is incorrect (e.g. in > HiveAuthzBindingHookBase) or else the way we are parsing the cached > privilege is incorrect (e.g. in SimplePrivilegeCache/CommonPrivilege). > > Colm. > >> On Wed, Dec 13, 2017 at 5:57 AM, Na Li <lina...@cloudera.com> wrote: >> >> Colm, >> >> I did not get chance to look into this issue today. Sorry about that. >> >> You can add a e2e test case and set break point at where the authorization >> object hierarchy to a list of authorization objects, which is used to do >> exact match with cache >> >> Sent from my iPhone >> >>> On Dec 12, 2017, at 11:27 AM, Colm O hEigeartaigh <cohei...@apache.org> >> wrote: >>> >>> That would be great, thanks! >>> >>> Colm. >>> >>>> On Tue, Dec 12, 2017 at 4:36 PM, Na Li <lina...@cloudera.com> wrote: >>>> >>>> Colm, >>>> >>>> I suspect it is a bug in SENTRY-1291. I can take a look later today. >>>> >>>> Thanks, >>>> >>>> Lina >>>> >>>> On Tue, Dec 12, 2017 at 4:32 AM, Colm O hEigeartaigh < >> cohei...@apache.org> >>>> wrote: >>>> >>>>> Hi all, >>>>> >>>>> I've updated some local testcases to work with Sentry 2.0.0 and the >> "v1" >>>>> Hive binding (previously working fine using 1.8.0 and the "v2" >> binding). >>>>> >>>>> I have a simple table called "words" (word STRING, count INT). I am >>>> making >>>>> an SQL call as the user "bob", e.g. "SELECT * FROM words where count == >>>>> '100'". >>>>> >>>>> "bob" is in the "manager" group", which has the following role: >>>>> >>>>> select_all_role = >>>>> Server=server1->Db=authz->Table=words->Column=*->action=select >>>>> >>>>> Essentially, authorization is denied even though the policy is correct. >>>> If >>>>> I look at the SimplePrivilegeCache, the cached privilege is: >>>>> >>>>> server=server1->db=authz->table=words->column=*=[Server= >>>>> server1->Db=authz->Table=words->Column=*->action=select] >>>>> >>>>> However, when "listPrivileges" is called, the authorizable hierarchy >>>> looks >>>>> like: >>>>> >>>>> Server [name=server1] >>>>> Database [name=authz] >>>>> Table [name=words] >>>>> >>>>> There is no "column" here, and a match is not made against the cached >>>>> privilege as a result. Is this a bug or am I missing some configuration >>>>> switch? >>>>> >>>>> Colm. >>>>> >>>>> >>>>> -- >>>>> Colm O hEigeartaigh >>>>> >>>>> Talend Community Coder >>>>> http://coders.talend.com >>>>> >>>> >>> >>> >>> >>> -- >>> Colm O hEigeartaigh >>> >>> Talend Community Coder >>> http://coders.talend.com >> > > > > -- > Colm O hEigeartaigh > > Talend Community Coder > http://coders.talend.com
