Rushabh S Shah created HADOOP-15459:
---------------------------------------
Summary: KMSACLs will fail for other optype if acls is defined for
one optype.
Key: HADOOP-15459
URL: https://issues.apache.org/jira/browse/HADOOP-15459
Project: Hadoop Common
Issue Type: Bug
Components: kms
Affects Versions: 2.8.3
Reporter: Rushabh S Shah
Assume subset of kms-acls xml file.
{noformat}
<property>
<name>default.key.acl.DECRYPT_EEK</name>
<value></value>
<description>
default ACL for DECRYPT_EEK operations for all key acls that are not
explicitly defined.
</description>
</property>
<configuration>
<property>
<name>key.acl.key1.DECRYPT_EEK</name>
<value>user1</value>
</property>
<property>
<name>default.key.acl.READ</name>
<value>*</value>
<description>
default ACL for READ operations for all key acls that are not
explicitly defined.
</description>
</property>
<property>
<name>whitelist.key.acl.READ</name>
<value>hdfs</value>
<description>
Whitelist ACL for READ operations for all keys.
</description>
</property>
{noformat}
For key {{key1}}, we restricted {{DECRYPT_EEK}} operation to only {{user1}}.
For other {{READ}} operation(like getMetadata), by default I still want
everyone to access all keys via {{default.key.acl.READ}}
But it doesn't allow anyone to access {{key1}} for any other READ operations.
As a result of this, if the admin restricted access for one opType then (s)he
has to define access for all other opTypes also, which is not desirable.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-dev-h...@hadoop.apache.org
