[
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:
------------------------------------------
[~daryn],
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
(v6.2#6252)
