[
https://issues.apache.org/jira/browse/HDFS-6826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14114385#comment-14114385
]
Alejandro Abdelnur commented on HDFS-6826:
------------------------------------------
Regarding my action item #2, based on @daryn’s suggestion, I’ve move all data
authz interception to the {{FsPermissionChecker}}, something like:
*Adding the following methods:*
{code}
private String getUserName(INode[] nodes) {
return AuthorizationProvider.get().getUser(nodes);
}
private String getGroupName(INode[] nodes) {
// wee need to recreate INode[] using the snapshot version of the nodes,
here or before calling
return AuthorizationProvider.get().getGroup(nodes);
}
private FsPermission getFsPermission(INode[] nodes) {
return AuthorizationProvider.get().getFsPermission(nodes);
}
private AclFeature getAclFeature(INode[] nodes) {
return AuthorizationProvider.get().getAclFeature(nodes);
}
{code}
And then replacing all the calls user/group/permissions/acls getters of INodes
calls within {{FsPermissionChecker}} to use the above methods, ie:
The intention was to be able to reuse the already calculated {{INode[]}} chain.
The issues I’m running with this are:
* The {{INode[]}} chain calculated on the entry point of checkPermission does
not take into account snapshots, thus we will need to recalculate the
{{INode[]}} to use the right snapshot for the full chain.
* All the logic in {{FSPermissionChecker}} has to be redone to pass the
{{INode[]}} chain around. This will get tricky as in many places direct array
access like this 'checkStickyBit(inodes[inodes.length - 2], last, snapshotId);'
are being done. And this is not always done on the snapshot version of the
{{INode}}.
* The {{INode[]}} may have null elements, complicating things on the plugin
side.
* We’ll have to do the same in the {{FSDirectory}} to create file status.
Another issue is that doing this, the plugin is only intercepting getter calls,
not setter calls.
Overall, it seems the plugin will have to be more complex than with the v7
approach, it will have less functionality (no writes, no snapshots), and it
will require some serious rewriting of the {{FsPermissionChecker}}.
> 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.3.patch,
> HDFS-6826v7.4.patch, HDFS-6826v7.5.patch, HDFS-6826v7.6.patch,
> HDFS-6826v7.patch, HDFS-6826v8.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)
