[
https://issues.apache.org/jira/browse/HDFS-6826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14109221#comment-14109221
]
Daryn Sharp commented on HDFS-6826:
-----------------------------------
Sorry I disappeared, 2.x deployment issues are keeping me busy. I strongly
object to the design. The concept is fine.
[~tucu00] explained to me offline about how this is intended to work with hive.
Users spray partition files all over the place. These files represent a
logical entity with its own authz scheme. A directory could easily control the
permissions but we're letting the tail wag the dog, a path sensitive plugin, to
accommodate disorganization.
The way I see it is the approach must maintain the semantics of a filesystem.
Permissions _are_ the authz for a filesystem. A plugin cannot impose
magical/hidden authz on a file. Imagine the user/admin confusion that will
arise. Instead we need to creatively leverage the existing semantics and allow
additional authz restrictions that are still viewable. We have user, group,
ACLs, and xattrs to work with.
After internal discussion, the cleaner approach that maintains fs semantics is
a plugin that may return additional fake & immutable (from the user's
perspective) ACLs. Further, external path sensitivity is fragile. If the file
or any parent directory is mutable, simply renaming the tree will effectively
drop the faked authz. You should associate something with a path, like perhaps
an immutable xattr that indicates the plugin should be queried for additional
ACLs. You may even use the xattr value to indicate the file table for quick &
easy lookups.
> 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.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.2#6252)
