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 <[email protected]> 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 >
