[jira] [Updated] (HADOOP-15459) KMSACLs will fail for other optype if acls is defined for one optype.

2018-05-17 Thread Rushabh S Shah (JIRA)

 [ 
https://issues.apache.org/jira/browse/HADOOP-15459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rushabh S Shah updated HADOOP-15459:

Resolution: Invalid
Status: Resolved  (was: Patch Available)

Gave a little bit more thought to this jira.
This change will bring semantic change to how acls are handled today.
Due to security reasons, if an admin granted access to one opType per key acl, 
(s)he has to grant access to all opTypes.
If an admin makes a typo in one opType, after this change it will fallback to 
default for that opType which is not desirable.
So closing this ticket as Invalid.

> 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
>Assignee: Rushabh S Shah
>Priority: Critical
> Attachments: HADOOP-15459.001.patch, HADOOP-15459.002.patch
>
>
> Assume subset of kms-acls xml file.
> {noformat}
>   
> default.key.acl.DECRYPT_EEK
> 
> 
>   default ACL for DECRYPT_EEK operations for all key acls that are not
>   explicitly defined.
> 
>   
> 
>   
> key.acl.key1.DECRYPT_EEK
> user1
>   
>   
> default.key.acl.READ
> *
> 
>   default ACL for READ operations for all key acls that are not
>   explicitly defined.
> 
>   
> 
>   whitelist.key.acl.READ
>   hdfs
>   
> Whitelist ACL for READ operations for all keys.
>   
> 
> {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-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org



[jira] [Updated] (HADOOP-15459) KMSACLs will fail for other optype if acls is defined for one optype.

2018-05-16 Thread Rushabh S Shah (JIRA)

 [ 
https://issues.apache.org/jira/browse/HADOOP-15459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rushabh S Shah updated HADOOP-15459:

Attachment: HADOOP-15459.002.patch

> 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
>Assignee: Rushabh S Shah
>Priority: Critical
> Attachments: HADOOP-15459.001.patch, HADOOP-15459.002.patch
>
>
> Assume subset of kms-acls xml file.
> {noformat}
>   
> default.key.acl.DECRYPT_EEK
> 
> 
>   default ACL for DECRYPT_EEK operations for all key acls that are not
>   explicitly defined.
> 
>   
> 
>   
> key.acl.key1.DECRYPT_EEK
> user1
>   
>   
> default.key.acl.READ
> *
> 
>   default ACL for READ operations for all key acls that are not
>   explicitly defined.
> 
>   
> 
>   whitelist.key.acl.READ
>   hdfs
>   
> Whitelist ACL for READ operations for all keys.
>   
> 
> {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-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org



[jira] [Updated] (HADOOP-15459) KMSACLs will fail for other optype if acls is defined for one optype.

2018-05-16 Thread Rushabh S Shah (JIRA)

 [ 
https://issues.apache.org/jira/browse/HADOOP-15459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rushabh S Shah updated HADOOP-15459:

Attachment: HADOOP-15459.001.patch

> 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
>Assignee: Rushabh S Shah
>Priority: Critical
> Attachments: HADOOP-15459.001.patch
>
>
> Assume subset of kms-acls xml file.
> {noformat}
>   
> default.key.acl.DECRYPT_EEK
> 
> 
>   default ACL for DECRYPT_EEK operations for all key acls that are not
>   explicitly defined.
> 
>   
> 
>   
> key.acl.key1.DECRYPT_EEK
> user1
>   
>   
> default.key.acl.READ
> *
> 
>   default ACL for READ operations for all key acls that are not
>   explicitly defined.
> 
>   
> 
>   whitelist.key.acl.READ
>   hdfs
>   
> Whitelist ACL for READ operations for all keys.
>   
> 
> {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-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org



[jira] [Updated] (HADOOP-15459) KMSACLs will fail for other optype if acls is defined for one optype.

2018-05-16 Thread Rushabh S Shah (JIRA)

 [ 
https://issues.apache.org/jira/browse/HADOOP-15459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rushabh S Shah updated HADOOP-15459:

Status: Patch Available  (was: Open)

> 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
>Assignee: Rushabh S Shah
>Priority: Critical
> Attachments: HADOOP-15459.001.patch
>
>
> Assume subset of kms-acls xml file.
> {noformat}
>   
> default.key.acl.DECRYPT_EEK
> 
> 
>   default ACL for DECRYPT_EEK operations for all key acls that are not
>   explicitly defined.
> 
>   
> 
>   
> key.acl.key1.DECRYPT_EEK
> user1
>   
>   
> default.key.acl.READ
> *
> 
>   default ACL for READ operations for all key acls that are not
>   explicitly defined.
> 
>   
> 
>   whitelist.key.acl.READ
>   hdfs
>   
> Whitelist ACL for READ operations for all keys.
>   
> 
> {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-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org