[
https://issues.apache.org/jira/browse/SENTRY-988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yongjun Zhang updated SENTRY-988:
---------------------------------
Description:
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).
Thanks [~sravya] for the discussion.
was:
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}
1. dir.setOwner(src, username, group);
2. 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).
Thanks [~sravya] for the discussion.
> 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
>
> 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).
> Thanks [~sravya] for the discussion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
