[ 
https://issues.apache.org/jira/browse/SENTRY-988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15060570#comment-15060570
 ] 

Sravya Tirukkovalur commented on SENTRY-988:
--------------------------------------------

About dropping the check "aclFeature.getClass() != SentryAclFeature.class" in 
removeAclFeature:
I would prefer to keep it for now. Seems unlikely but not sure if there are any 
cases where removeAclFeature is called on the result of getACLFeature (shadowed 
by sentry), in which case we do not want to remove these from defaultProvider. 
Note that they are public APIs, so we cannot be sure how they are used.

> It's better to let SentryAuthorization setter path always fall through and 
> update HDFS
> --------------------------------------------------------------------------------------
>
>                 Key: SENTRY-988
>                 URL: https://issues.apache.org/jira/browse/SENTRY-988
>             Project: Sentry
>          Issue Type: Bug
>          Components: Hdfs Plugin
>            Reporter: Yongjun Zhang
>            Assignee: Yongjun Zhang
>         Attachments: SENTRY-988.001.patch, SENTRY-988.002.patch
>
>
> Currently SentryAuthorizationProvider rejects setter calls to Sentry-managed 
> paths, and issue an error message when enabled.
> There are two issues:
> 1. When creating a file or dir, the parent dir's group will be set to the 
> newly created file/dir, this is supposed to be logged to fsimage in-memory 
> representation, but because the rejection of Sentry, it's not.
> 2. (as an example) When user issue a setOwner call via the following RPC:
> {code}
> @Override // ClientProtocol
>   public void setOwner(String src, String username, String groupname)
>       throws IOException {
>     checkNNStartup();
>     namesystem.setOwner(src, username, groupname);
>   }
> {code}
> Two calls are executed in the deep stack:
> {code}
> a.     dir.setOwner(src, username, group);
> b.     getEditLog().logSetOwner(src, username, group);
> {code}
> The first call is the one gets rejected by Sentry, however, the second one 
> still updates the entry to Edit log. This would indicate an inconsistency 
> between in-memory representation of the attribute and what's recorded on edit 
> log.
> Creating this jira to make SentryAuthorizationProvider always fallthrough to 
> write to HDFS, and issue a warning msg when it "rejects" (for Sentry-managed 
> paths).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to