[
https://issues.apache.org/jira/browse/HDFS-6826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alejandro Abdelnur updated HDFS-6826:
-------------------------------------
Attachment: HDFS-6826v9.patch
Attached, v9, is a functioning patch based on [~daryn] idea. It requires a
little refining.
A few comments on the approach:
* Instead being invasive on the {{INode}} classes, it is invasive in the
{{PermissionChecker}} and in the {{FSDirectory}}.
* It does not allow to replace the permission check logic (v7.x does) (could be
done in a follow up JIRA)
* It does not allow to replace the setter of authz info logic (v7.x does)
* It seems to be more efficient regarding the times it gets call and how the
full path can be inferred by the plugin.
* Talking with Daryn, he suggested doing some changes in the {{FSDirectory}}
for creating file status by passing. I'm deferring this to the refactoring he
wants to do as it is not that trivial.
Refining required:
* How to handle setting of authz info, meaning fully ignoring setter calls for
a path managed by a plugin. Else setters have effect. The plugin should be able
to prevent those setter calls from happening.
* subAccess check is a TODO, the stack logic there needs to carry more info
for the plugin (but we don't want to do that if there is no plugin).
The v7.6 and the v9 plugins provide the functionality it is needed for
HMS/Sentry. I'm OK either way.
Could others weight on the preferred approach? I would like to get closure on
this ASAP for Sentry to start building on top of it.
> Plugin interface to enable delegation of HDFS authorization assertions
> ----------------------------------------------------------------------
>
> Key: HDFS-6826
> URL: https://issues.apache.org/jira/browse/HDFS-6826
> Project: Hadoop HDFS
> Issue Type: New Feature
> Components: security
> Affects Versions: 2.4.1
> Reporter: Alejandro Abdelnur
> Assignee: Alejandro Abdelnur
> Attachments: HDFS-6826-idea.patch, HDFS-6826-idea2.patch,
> HDFS-6826-permchecker.patch, HDFS-6826v3.patch, HDFS-6826v4.patch,
> HDFS-6826v5.patch, HDFS-6826v6.patch, HDFS-6826v7.1.patch,
> HDFS-6826v7.2.patch, HDFS-6826v7.3.patch, HDFS-6826v7.4.patch,
> HDFS-6826v7.5.patch, HDFS-6826v7.6.patch, HDFS-6826v7.patch,
> HDFS-6826v8.patch, HDFS-6826v9.patch,
> HDFSPluggableAuthorizationProposal-v2.pdf,
> HDFSPluggableAuthorizationProposal.pdf
>
>
> When Hbase data, HiveMetaStore data or Search data is accessed via services
> (Hbase region servers, HiveServer2, Impala, Solr) the services can enforce
> permissions on corresponding entities (databases, tables, views, columns,
> search collections, documents). It is desirable, when the data is accessed
> directly by users accessing the underlying data files (i.e. from a MapReduce
> job), that the permission of the data files map to the permissions of the
> corresponding data entity (i.e. table, column family or search collection).
> To enable this we need to have the necessary hooks in place in the NameNode
> to delegate authorization to an external system that can map HDFS
> files/directories to data entities and resolve their permissions based on the
> data entities permissions.
> I’ll be posting a design proposal in the next few days.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
