sentry-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yongjun Zhang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SENTRY-988) It's better to let SentryAuthorization setter path always fall through and update HDFS
Date Fri, 18 Dec 2015 05:31:46 GMT

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

Yongjun Zhang commented on SENTRY-988:
--------------------------------------

Hi [~sravya], many thanks for the review and commit!


> 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
>             Fix For: 1.7.0
>
>         Attachments: SENTRY-988.001.patch, SENTRY-988.002.patch, SENTRY-988.003.patch,
SENTRY-988.004.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)

Mime
View raw message