[
https://issues.apache.org/jira/browse/HDFS-6826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14136588#comment-14136588
]
Jitendra Nath Pandey commented on HDFS-6826:
--------------------------------------------
bq. Argus was described as a means to augment the permissions with acls via
"policies" that cannot be represented in hdfs such as time/network based, etc.
As I understand, Argus would also need ability to add policies on files and
directories including wild cards.
bq. Allowing the entire permissions to be modified to be non-posix(ish)
compliant is a major change that will break many stack components. A more in
depth analysis and discussion of the impact is required.
The reason for exposing a plugin interface is to allow different organizations
to have different models. The default behavior doesn't change at all, therefore
there is no risk to the stack. The cluster admins that choose to use their own
plugins would do that under their security policy encompassing the stack in
their org and would be responsible for compatibility with other components.
bq. Alejandro simply needs to substitute "fake" inode attributes so hopefully
we can postpone to another jira..
We need to see the use case, faking inode attributes is an implementation. The
use case is to externalize the authorization provisioning. In that respect,
HMS/Sentry use case is not that far from Argus. Since we have two use cases in
this area, it also indicates that users have different security policies and
need us to allow using different permission models. Since we are exposing a
plugin here, we should look at all the known use cases and think of a design
that covers those use cases. Of course, we don't want multiple interfaces and
multiple plugins with nuances for the same area of the code and functionality.
I don't fully understand your reservations on v7.6. This patch covers the
known use cases at this point. It doesn't change the default behavior of the
system at all. It provides lot more flexibility to the plugin writers to suit
their security policies and of course it is their risk. The patch has gone
through many iterations and seems to be pretty mature now and will address the
needs for both Argus and HMS/Sentry.
> 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-6826-permchecker.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, HDFS-6826v9.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.3.4#6332)
