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
