hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daryn Sharp (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-6826) Plugin interface to enable delegation of HDFS authorization assertions
Date Mon, 25 Aug 2014 15:44:00 GMT

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

Mime
View raw message