Sasha,
sentry-1291 is helpful for the problem that sentry privilege checks takes
too long with many explicit grants, which is useful for big customers.
Another approach that can improve the performance is to organize the
privileges according to the authorization hierarchy in a tree structure, so
finding match in ResourceAuthorizationProvider.doHasAccess() is in the
order of log(N), not linear of N, where N is the number of privileges.
We can wait for Colm to confirm his issue is caused by sentry-1291. If so,
it may be fixed by selecting privileges by finding if the requesting
authorization object is prefix of cached privileges instead of exact match.
in SimplePrivilegeCache
public Set<String> listPrivileges(Set<String> groups, Set<String> users,
ActiveRoleSet roleSet,
Authorizable... authorizationHierarchy) {
Set<String> privileges = new HashSet<>();
Set<StringBuilder> authzKeys = getAuthzKeys(authorizationHierarchy);
for (StringBuilder authzKey : authzKeys) {
if (cachedAuthzPrivileges.get(authzKey.toString()) != null) { <-
instead of exact matching, add extension function to check if
authzKey.toString is the prefix of the key of the entries
in cachedAuthzPrivileges.
privileges.addAll(cachedAuthzPrivileges.get(authzKey.toString()));
}
}
return privileges;
}
Thanks,
Lina
On Wed, Dec 13, 2017 at 1:08 PM, Alexander Kolbasov <ak...@cloudera.com>
wrote:
> 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
> >
>
