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
