I think that SENTRY-1291 should be just reverted - there are multiple issues with it and no one is actually using the fix. Anyone wants to do it?
- Alex On Wed, Dec 13, 2017 at 4:44 AM, Na Li <lina...@cloudera.com> wrote: > 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 >
