[
https://issues.apache.org/jira/browse/HDFS-6826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14134006#comment-14134006
]
Daryn Sharp commented on HDFS-6826:
-----------------------------------
Apologies for my delay, again. Awhile back, Alejandro and I spoke offline
about how hooking in at the inode level and/or allowing a plugin to completely
override the permission checking logic is detrimental. The latest patch
doesn't directly splice into the inodes, but for reference the reason it's bad
is because replaying edits, whether at startup or HA standby, should not ever
go through the plugin.
Allowing complete override of the permission checking is bad too. Plugins
should not be in control of the traversal or iteration of inodes. The plugin
should be just that - a hook for the core permission checking. Otherwise
plugins will be fragile when changes are made to path resolution. And/or
plugins will have to implement duplicated logic.
With backlogged feature work I'm doing for optional fine grain locks, path
resolution, the locking, and permission checking will all be folded together.
In order for locking to work, inodes will be "resolved as you go". About the
only way to ensure compatibility is for the permission checker to have a hook
to call out to the plugin. The plugin cannot override the core behavior.
I'll attach an incomplete example patch for how an external plugin can
substitute different inode attrs during a resolution. It can be further
optimized (I scaled it back) but it demonstrates the basic principle. It
doesn't address that argus needs another hook to provide further permission
checks but it meets Alejandro's needs. An enhancement for argus can be another
jira.
> 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-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,
> 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)
