hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alejandro Abdelnur (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-6826) Plugin interface to enable delegation of HDFS authorization assertions
Date Wed, 13 Aug 2014 18:56:14 GMT

    [ https://issues.apache.org/jira/browse/HDFS-6826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14095930#comment-14095930

Alejandro Abdelnur commented on HDFS-6826:


bq. The group mapping authz is a bit different.  It's not context sensitive, as in a user
uniformly belongs to groups across the whole namesystem.  

Mmmhh, I’d argue that it is context sensitive, 'user' context, just a different context.

bq. Path-based context sensitivity is adding hidden magic to a filesystem.  How will the special
magic be represented to the user confused by why the perms/ACLs aren't being honored? 

The authorization enforcement semantics does not change at all. The plugin cannot change the
permission check logic.

The plugin is responsible for providing user/group/permissions/ACLs information to the NN
who enforces the permissions consistently regardless of the plugin in use.

bq. How will permission apis and FsShell interact with the magic?

The work as usual. Check the attached patch, the current HDFS user/group/permission/ACLs handling
is done by a plugin implementation.

Said that, a plugin implementation may decide to disable changes of user/group/permissions/ACLs.
This can be done either silently or failing.

bq. Instead of trying to hack special behavior for a specific use case into the NN, how about
leveraging what's there.

The proposal doc describes in detail 3 different usecases: HiveMetaStore tables, Hbase tables,
Solr search collections.

bq. A cleaner way may be for a custom group mapping to fabricate groups something like "hive:table"
or "hive:table:column".   No code changes in the NN.  Everything is contained in the custom
groups mapping.

This does not solve the problem. When adding a directory as a HiveMetaStore table partition,
unless you set those special groups explicitly, they would not be in the  files being added
to the table.

It requires client side group manipulation and this is what breaks things.

bq. I still think leveraging ACLs is the best way to go...

Actually, we are. In the case of HiveMetaStore, the plugin would expose GRANT permissions
as ACLs.

Daryn, I'm happy to jump on the phone if you want have a synchronous discussion.

> 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, 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

View raw message