[
https://issues.apache.org/jira/browse/HDFS-6826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14146399#comment-14146399
]
Daryn Sharp commented on HDFS-6826:
-----------------------------------
My main concern and opposition is the current approach so tightly couples the
plugin with the NN's current implementation that it will impede future
features. Too many implementation details are leaked or exposed for plugins
that ought not be. I have many changes related to combined path resolution,
locking, and permission checks that will be jeopardized.
Specific issues:
# It's all too tightly coupled to the current permission checker implementation
# The plugin will break every time a new namesystem method is added
# Block operations shouldn't be going through the plugin, should they?
# MAJOR: Splicing at the {{ClientNamenodeProtocolServerSideTranslatorPB}} level
allows webhdfs to sidestep the plugin
# Thread locals aren't always performant and they are used heavily primarily to
allow the plugin to avoid blowing up edit log processing because...
# Splicing into inodes is too low of a level. All authz checks should have
already been performed.
# Why splice into inode setters since checked exceptions cannot be thrown?
Silently ignoring the set will discombobulate the user. Throwing a runtime
exception may leave the namesystem in an inconsistent state, thus I don't see
the value add.
# Setters in {{DefaultAuthorizationProvider}} are too fragile. It's exposing
too many implementation details as to how inode information is encoded - today.
# Using a static for the provider allows one and only one custom authz
provider. What if the user wants to use _both_ sentry and argus?
Now let's look at the two use cases, correct me if I'm wrong:
* Argus: wants to augment the permission model for acls that cannot be
represented in hdfs acls
* Sentry: wants to return fake user/group/perms to avoid having other stack
components own their backing files
Based our offline discussion of Argus, it should be the easiest to implement
based on the explicit agreement it will only augment the permission model.
Just needs an additional callout.
The Sentry use case is a bit dubious but generally simple to add in a manner
that doesn't complicate future changes. It just needs to substitute inode
attributes prior to the standard permission checks. The file status change may
seem like a hack (today) but it will dovetail with fsdir changes to only
operate on pre-resolved inodes - not re-resolved paths. File status will
simply return the attributes of the last node which will conveniently be the
dummy values already substituted by the plugin.
> 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)
