[SENTRY-988] It's better to let SentryAuthorization setter path always fall through and update HDFS

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 1.7.0
• Component/s: Hdfs Plugin
• Assignee: Yongjun Zhang
• Reporter: Yongjun Zhang
• Created: 15/Dec/15 23:43
• Updated: 04/Jan/16 22:35
• Resolved: 17/Dec/15 23:02

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:

@Override // ClientProtocol
  public void setOwner(String src, String username, String groupname)
      throws IOException {
    checkNNStartup();
    namesystem.setOwner(src, username, groupname);
  }

Two calls are executed in the deep stack:

a.     dir.setOwner(src, username, group);
b.     getEditLog().logSetOwner(src, username, group);

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).

Issue Links

• relates to: SENTRY-954 HDFS ACLs are not correctly managed for paths under prefix but not hive objects.