Permissions on URI are not propagated to namenode plugin

[Qianbo Huai <qi...@uber.com>]

Hi Sentry Dev,

Can you help confirm if our finding (as title) is correct?

Here are the details. We are using Sentry cdh5-1.5.1_5.7.2. During our
testing, we noticed that URI privilege / permission are not propagated to
the sentry namenode plugin. For example, suppose we grant the following
privilege to a testrole:

   - beeline> grant select on uri 'hdfs://ns-default/somepath/somefile' to
   role testrole

When sentry service receives the grant request from hiveserver2, it
persists it to its database and triggers a notification, which reaches
SentryPlugin.onAlterSentryRoleGrantPrivilegeCore, with this
TSentryPrivilege object.

   - TSentryPrivilege(privilegeScope:URI, serverName:hs2-server1, dbName:,
   tableName:, hdfs://ns-default/somepath/somefile, action:*,
   createTime:1493756627842, grantOption:FALSE, columnName:)

As getAuthzObj(privilege) returns null, the call to
onAlterSentryRoleGrantPrivilegeCore becomes a no-op, thus the
SentryPlugin's permsUpdater list is not updated.

Based on our finding, this behavior (URI perms not being propagated to
namenode plugin) seems by design. Correct? Is there any change regarding
this topic in later versions of Sentry?

Thanks
Qianbo Huai

Uber Data Infra Engineering

Re: Permissions on URI are not propagated to namenode plugin

[Sergio Pena <se...@cloudera.com>]

Hey Quianbo,

This issue seems it is by design as you mentioned. I was reading the design
doc on SENTRY-432 and it has this line in the assumptions section:

3. If the HDFS URI matches a prefix but it does not belong to a
> HiveMetaStore table, the
> regular HDFS user/group/permissions/ACLs are used.


I looked at the current code and this is still the current behavior even on
the new Sentry HA redesign feature.

I don't know why it was designed that way, perhaps it wasn't considered to
be fixed right away. Feel free to file a new JIRA if you feel this is
something useful for users.

Sergio

On Wed, May 3, 2017 at 1:31 PM, Qianbo Huai <qi...@uber.com> wrote:

> Hi Sentry Dev,
>
> Can you help confirm if our finding (as title) is correct?
>
> Here are the details. We are using Sentry cdh5-1.5.1_5.7.2. During our
> testing, we noticed that URI privilege / permission are not propagated to
> the sentry namenode plugin. For example, suppose we grant the following
> privilege to a testrole:
>
>    - beeline> grant select on uri 'hdfs://ns-default/somepath/somefile' to
>    role testrole
>
> When sentry service receives the grant request from hiveserver2, it
> persists it to its database and triggers a notification, which reaches
> SentryPlugin.onAlterSentryRoleGrantPrivilegeCore, with this
> TSentryPrivilege object.
>
>    - TSentryPrivilege(privilegeScope:URI, serverName:hs2-server1, dbName:,
>    tableName:, hdfs://ns-default/somepath/somefile, action:*,
>    createTime:1493756627842, grantOption:FALSE, columnName:)
>
> As getAuthzObj(privilege) returns null, the call to
> onAlterSentryRoleGrantPrivilegeCore becomes a no-op, thus the
> SentryPlugin's permsUpdater list is not updated.
>
> Based on our finding, this behavior (URI perms not being propagated to
> namenode plugin) seems by design. Correct? Is there any change regarding
> this topic in later versions of Sentry?
>
> Thanks
> Qianbo Huai
>
> Uber Data Infra Engineering
>