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
