[jira] [Updated] (HADOOP-12640) Code Review AccessControlList
[ https://issues.apache.org/jira/browse/HADOOP-12640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] BELUGA BEHR updated HADOOP-12640: - Status: Patch Available (was: Open) > Code Review AccessControlList > - > > Key: HADOOP-12640 > URL: https://issues.apache.org/jira/browse/HADOOP-12640 > Project: Hadoop Common > Issue Type: Improvement > Components: security >Affects Versions: 3.2.0 >Reporter: BELUGA BEHR >Assignee: BELUGA BEHR >Priority: Minor > Attachments: AccessControlList.patch, AccessControlList.patch, > HADOOP-12640.1.patch > > > After some confusion of my own, in particular with > "mapreduce.job.acl-view-job," I have looked over the AccessControlList > implementation and cleaned it up and clarified a few points. > 1) I added tests to demonstrate the existing behavior of including an > asterisk in either the username or the group field, it overrides everything > and allows all access. > "user1,user2,user3 *" = all access > "* group1,group2" = all access > "* *" = all access > "* " = all access > " *" = all access > 2) General clean-up and simplification -- 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-12640) Code Review AccessControlList
[ https://issues.apache.org/jira/browse/HADOOP-12640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] BELUGA BEHR updated HADOOP-12640: - Attachment: HADOOP-12640.1.patch > Code Review AccessControlList > - > > Key: HADOOP-12640 > URL: https://issues.apache.org/jira/browse/HADOOP-12640 > Project: Hadoop Common > Issue Type: Improvement > Components: security >Affects Versions: 3.2.0 >Reporter: BELUGA BEHR >Assignee: BELUGA BEHR >Priority: Minor > Attachments: AccessControlList.patch, AccessControlList.patch, > HADOOP-12640.1.patch > > > After some confusion of my own, in particular with > "mapreduce.job.acl-view-job," I have looked over the AccessControlList > implementation and cleaned it up and clarified a few points. > 1) I added tests to demonstrate the existing behavior of including an > asterisk in either the username or the group field, it overrides everything > and allows all access. > "user1,user2,user3 *" = all access > "* group1,group2" = all access > "* *" = all access > "* " = all access > " *" = all access > 2) General clean-up and simplification -- 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-12640) Code Review AccessControlList
[ https://issues.apache.org/jira/browse/HADOOP-12640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] BELUGA BEHR updated HADOOP-12640: - Attachment: (was: HADOOP-12640.1.patch) > Code Review AccessControlList > - > > Key: HADOOP-12640 > URL: https://issues.apache.org/jira/browse/HADOOP-12640 > Project: Hadoop Common > Issue Type: Improvement > Components: security >Affects Versions: 3.2.0 >Reporter: BELUGA BEHR >Assignee: BELUGA BEHR >Priority: Minor > Attachments: AccessControlList.patch, AccessControlList.patch > > > After some confusion of my own, in particular with > "mapreduce.job.acl-view-job," I have looked over the AccessControlList > implementation and cleaned it up and clarified a few points. > 1) I added tests to demonstrate the existing behavior of including an > asterisk in either the username or the group field, it overrides everything > and allows all access. > "user1,user2,user3 *" = all access > "* group1,group2" = all access > "* *" = all access > "* " = all access > " *" = all access > 2) General clean-up and simplification -- 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-12640) Code Review AccessControlList
[ https://issues.apache.org/jira/browse/HADOOP-12640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] BELUGA BEHR updated HADOOP-12640: - Status: Open (was: Patch Available) > Code Review AccessControlList > - > > Key: HADOOP-12640 > URL: https://issues.apache.org/jira/browse/HADOOP-12640 > Project: Hadoop Common > Issue Type: Improvement > Components: security >Affects Versions: 3.2.0 >Reporter: BELUGA BEHR >Assignee: BELUGA BEHR >Priority: Minor > Attachments: AccessControlList.patch, AccessControlList.patch > > > After some confusion of my own, in particular with > "mapreduce.job.acl-view-job," I have looked over the AccessControlList > implementation and cleaned it up and clarified a few points. > 1) I added tests to demonstrate the existing behavior of including an > asterisk in either the username or the group field, it overrides everything > and allows all access. > "user1,user2,user3 *" = all access > "* group1,group2" = all access > "* *" = all access > "* " = all access > " *" = all access > 2) General clean-up and simplification -- 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-12640) Code Review AccessControlList
[ https://issues.apache.org/jira/browse/HADOOP-12640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] BELUGA BEHR updated HADOOP-12640: - Attachment: HADOOP-12640.1.patch > Code Review AccessControlList > - > > Key: HADOOP-12640 > URL: https://issues.apache.org/jira/browse/HADOOP-12640 > Project: Hadoop Common > Issue Type: Improvement > Components: security >Affects Versions: 3.2.0 >Reporter: BELUGA BEHR >Assignee: BELUGA BEHR >Priority: Minor > Attachments: AccessControlList.patch, AccessControlList.patch, > HADOOP-12640.1.patch > > > After some confusion of my own, in particular with > "mapreduce.job.acl-view-job," I have looked over the AccessControlList > implementation and cleaned it up and clarified a few points. > 1) I added tests to demonstrate the existing behavior of including an > asterisk in either the username or the group field, it overrides everything > and allows all access. > "user1,user2,user3 *" = all access > "* group1,group2" = all access > "* *" = all access > "* " = all access > " *" = all access > 2) General clean-up and simplification -- 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-12640) Code Review AccessControlList
[ https://issues.apache.org/jira/browse/HADOOP-12640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] BELUGA BEHR updated HADOOP-12640: - Status: Patch Available (was: Open) > Code Review AccessControlList > - > > Key: HADOOP-12640 > URL: https://issues.apache.org/jira/browse/HADOOP-12640 > Project: Hadoop Common > Issue Type: Improvement > Components: security >Affects Versions: 3.2.0 >Reporter: BELUGA BEHR >Assignee: BELUGA BEHR >Priority: Minor > Attachments: AccessControlList.patch, AccessControlList.patch, > HADOOP-12640.1.patch > > > After some confusion of my own, in particular with > "mapreduce.job.acl-view-job," I have looked over the AccessControlList > implementation and cleaned it up and clarified a few points. > 1) I added tests to demonstrate the existing behavior of including an > asterisk in either the username or the group field, it overrides everything > and allows all access. > "user1,user2,user3 *" = all access > "* group1,group2" = all access > "* *" = all access > "* " = all access > " *" = all access > 2) General clean-up and simplification -- 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-12640) Code Review AccessControlList
[ https://issues.apache.org/jira/browse/HADOOP-12640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] BELUGA BEHR updated HADOOP-12640: - Status: Open (was: Patch Available) > Code Review AccessControlList > - > > Key: HADOOP-12640 > URL: https://issues.apache.org/jira/browse/HADOOP-12640 > Project: Hadoop Common > Issue Type: Improvement > Components: security >Affects Versions: 2.7.1 >Reporter: BELUGA BEHR >Assignee: BELUGA BEHR >Priority: Minor > Attachments: AccessControlList.patch, AccessControlList.patch > > > After some confusion of my own, in particular with > "mapreduce.job.acl-view-job," I have looked over the AccessControlList > implementation and cleaned it up and clarified a few points. > 1) I added tests to demonstrate the existing behavior of including an > asterisk in either the username or the group field, it overrides everything > and allows all access. > "user1,user2,user3 *" = all access > "* group1,group2" = all access > "* *" = all access > "* " = all access > " *" = all access > 2) General clean-up and simplification -- 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-12640) Code Review AccessControlList
[ https://issues.apache.org/jira/browse/HADOOP-12640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] BELUGA BEHR updated HADOOP-12640: - Affects Version/s: (was: 2.7.1) 3.2.0 > Code Review AccessControlList > - > > Key: HADOOP-12640 > URL: https://issues.apache.org/jira/browse/HADOOP-12640 > Project: Hadoop Common > Issue Type: Improvement > Components: security >Affects Versions: 3.2.0 >Reporter: BELUGA BEHR >Assignee: BELUGA BEHR >Priority: Minor > Attachments: AccessControlList.patch, AccessControlList.patch > > > After some confusion of my own, in particular with > "mapreduce.job.acl-view-job," I have looked over the AccessControlList > implementation and cleaned it up and clarified a few points. > 1) I added tests to demonstrate the existing behavior of including an > asterisk in either the username or the group field, it overrides everything > and allows all access. > "user1,user2,user3 *" = all access > "* group1,group2" = all access > "* *" = all access > "* " = all access > " *" = all access > 2) General clean-up and simplification -- 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-12640) Code Review AccessControlList
[ https://issues.apache.org/jira/browse/HADOOP-12640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] BELUGA BEHR updated HADOOP-12640: - Attachment: AccessControlList.patch > Code Review AccessControlList > - > > Key: HADOOP-12640 > URL: https://issues.apache.org/jira/browse/HADOOP-12640 > Project: Hadoop Common > Issue Type: Improvement > Components: security >Affects Versions: 2.7.1 >Reporter: BELUGA BEHR >Priority: Minor > Attachments: AccessControlList.patch, AccessControlList.patch > > > After some confusion of my own, in particular with > "mapreduce.job.acl-view-job," I have looked over the AccessControlList > implementation and cleaned it up and clarified a few points. > 1) I added tests to demonstrate the existing behavior of including an > asterisk in either the username or the group field, it overrides everything > and allows all access. > "user1,user2,user3 *" = all access > "* group1,group2" = all access > "* *" = all access > "* " = all access > " *" = all access > 2) General clean-up and simplification -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HADOOP-12640) Code Review AccessControlList
[ https://issues.apache.org/jira/browse/HADOOP-12640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] BELUGA BEHR updated HADOOP-12640: - Attachment: (was: TestAccessControlList.path) > Code Review AccessControlList > - > > Key: HADOOP-12640 > URL: https://issues.apache.org/jira/browse/HADOOP-12640 > Project: Hadoop Common > Issue Type: Improvement > Components: security >Affects Versions: 2.7.1 >Reporter: BELUGA BEHR >Priority: Minor > > After some confusion of my own, in particular with > "mapreduce.job.acl-view-job," I have looked over the AccessControlList > implementation and cleaned it up and clarified a few points. > 1) I added tests to show that when including an asterisk in either the > username or the group field, it overrides everything and allows all access. > "user1,user2,user3 *" = all access > "* group1,group2" = all access > "* *" = all access > "* " = all access > " *" = all access > 2) General clean-up and simplification > 3) NOT-BACKWARDS COMPATIBLE > The code currently handled spaces in an asymmetric way. The code splits the > ACL string on a single space, but limits the resulting array to a size of > two. So, as long as there are no spaces in the user names section, it works > fine, but any spaces subsequent to that did not matter. > "user1,user2,user3 group1, group2,group3" - works as expected > ["user1,user2,user3", "group1, group2,group3"] > "user1, user2,user3 group1,group2,group3" - Did not work as expected > ["user1,","user2,user3, group1, group2,group3"] > The submitted patch will split on all spaces and log a warning if there are > more than two elements. This enforces no spaces with the two comma-separated > lists. > Update: > Perhaps this can be expanded to use a semi-colon as the delimiter between > users and groups, so any interwoven spaces can simply be ignored. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HADOOP-12640) Code Review AccessControlList
[ https://issues.apache.org/jira/browse/HADOOP-12640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] BELUGA BEHR updated HADOOP-12640: - Description: After some confusion of my own, in particular with "mapreduce.job.acl-view-job," I have looked over the AccessControlList implementation and cleaned it up and clarified a few points. 1) I added tests to demonstrate the existing behavior of including an asterisk in either the username or the group field, it overrides everything and allows all access. "user1,user2,user3 *" = all access "* group1,group2" = all access "* *" = all access "* " = all access " *" = all access 2) General clean-up and simplification was: After some confusion of my own, in particular with "mapreduce.job.acl-view-job," I have looked over the AccessControlList implementation and cleaned it up and clarified a few points. 1) I added tests to show that when including an asterisk in either the username or the group field, it overrides everything and allows all access. "user1,user2,user3 *" = all access "* group1,group2" = all access "* *" = all access "* " = all access " *" = all access 2) General clean-up and simplification 3) NOT-BACKWARDS COMPATIBLE The code currently handled spaces in an asymmetric way. The code splits the ACL string on a single space, but limits the resulting array to a size of two. So, as long as there are no spaces in the user names section, it works fine, but any spaces subsequent to that did not matter. "user1,user2,user3 group1, group2,group3" - works as expected ["user1,user2,user3", "group1, group2,group3"] "user1, user2,user3 group1,group2,group3" - Did not work as expected ["user1,","user2,user3, group1, group2,group3"] The submitted patch will split on all spaces and log a warning if there are more than two elements. This enforces no spaces with the two comma-separated lists. Update: Perhaps this can be expanded to use a semi-colon as the delimiter between users and groups, so any interwoven spaces can simply be ignored. > Code Review AccessControlList > - > > Key: HADOOP-12640 > URL: https://issues.apache.org/jira/browse/HADOOP-12640 > Project: Hadoop Common > Issue Type: Improvement > Components: security >Affects Versions: 2.7.1 >Reporter: BELUGA BEHR >Priority: Minor > Attachments: AccessControlList.patch > > > After some confusion of my own, in particular with > "mapreduce.job.acl-view-job," I have looked over the AccessControlList > implementation and cleaned it up and clarified a few points. > 1) I added tests to demonstrate the existing behavior of including an > asterisk in either the username or the group field, it overrides everything > and allows all access. > "user1,user2,user3 *" = all access > "* group1,group2" = all access > "* *" = all access > "* " = all access > " *" = all access > 2) General clean-up and simplification -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HADOOP-12640) Code Review AccessControlList
[ https://issues.apache.org/jira/browse/HADOOP-12640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] BELUGA BEHR updated HADOOP-12640: - Attachment: (was: AccessControlList.patch) > Code Review AccessControlList > - > > Key: HADOOP-12640 > URL: https://issues.apache.org/jira/browse/HADOOP-12640 > Project: Hadoop Common > Issue Type: Improvement > Components: security >Affects Versions: 2.7.1 >Reporter: BELUGA BEHR >Priority: Minor > > After some confusion of my own, in particular with > "mapreduce.job.acl-view-job," I have looked over the AccessControlList > implementation and cleaned it up and clarified a few points. > 1) I added tests to show that when including an asterisk in either the > username or the group field, it overrides everything and allows all access. > "user1,user2,user3 *" = all access > "* group1,group2" = all access > "* *" = all access > "* " = all access > " *" = all access > 2) General clean-up and simplification > 3) NOT-BACKWARDS COMPATIBLE > The code currently handled spaces in an asymmetric way. The code splits the > ACL string on a single space, but limits the resulting array to a size of > two. So, as long as there are no spaces in the user names section, it works > fine, but any spaces subsequent to that did not matter. > "user1,user2,user3 group1, group2,group3" - works as expected > ["user1,user2,user3", "group1, group2,group3"] > "user1, user2,user3 group1,group2,group3" - Did not work as expected > ["user1,","user2,user3, group1, group2,group3"] > The submitted patch will split on all spaces and log a warning if there are > more than two elements. This enforces no spaces with the two comma-separated > lists. > Update: > Perhaps this can be expanded to use a semi-colon as the delimiter between > users and groups, so any interwoven spaces can simply be ignored. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HADOOP-12640) Code Review AccessControlList
[ https://issues.apache.org/jira/browse/HADOOP-12640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] BELUGA BEHR updated HADOOP-12640: - Attachment: AccessControlList.patch > Code Review AccessControlList > - > > Key: HADOOP-12640 > URL: https://issues.apache.org/jira/browse/HADOOP-12640 > Project: Hadoop Common > Issue Type: Improvement > Components: security >Affects Versions: 2.7.1 >Reporter: BELUGA BEHR >Priority: Minor > Attachments: AccessControlList.patch > > > After some confusion of my own, in particular with > "mapreduce.job.acl-view-job," I have looked over the AccessControlList > implementation and cleaned it up and clarified a few points. > 1) I added tests to show that when including an asterisk in either the > username or the group field, it overrides everything and allows all access. > "user1,user2,user3 *" = all access > "* group1,group2" = all access > "* *" = all access > "* " = all access > " *" = all access > 2) General clean-up and simplification > 3) NOT-BACKWARDS COMPATIBLE > The code currently handled spaces in an asymmetric way. The code splits the > ACL string on a single space, but limits the resulting array to a size of > two. So, as long as there are no spaces in the user names section, it works > fine, but any spaces subsequent to that did not matter. > "user1,user2,user3 group1, group2,group3" - works as expected > ["user1,user2,user3", "group1, group2,group3"] > "user1, user2,user3 group1,group2,group3" - Did not work as expected > ["user1,","user2,user3, group1, group2,group3"] > The submitted patch will split on all spaces and log a warning if there are > more than two elements. This enforces no spaces with the two comma-separated > lists. > Update: > Perhaps this can be expanded to use a semi-colon as the delimiter between > users and groups, so any interwoven spaces can simply be ignored. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HADOOP-12640) Code Review AccessControlList
[ https://issues.apache.org/jira/browse/HADOOP-12640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] BELUGA BEHR updated HADOOP-12640: - Status: Patch Available (was: Open) > Code Review AccessControlList > - > > Key: HADOOP-12640 > URL: https://issues.apache.org/jira/browse/HADOOP-12640 > Project: Hadoop Common > Issue Type: Improvement > Components: security >Affects Versions: 2.7.1 >Reporter: BELUGA BEHR >Priority: Minor > Attachments: AccessControlList.patch > > > After some confusion of my own, in particular with > "mapreduce.job.acl-view-job," I have looked over the AccessControlList > implementation and cleaned it up and clarified a few points. > 1) I added tests to show that when including an asterisk in either the > username or the group field, it overrides everything and allows all access. > "user1,user2,user3 *" = all access > "* group1,group2" = all access > "* *" = all access > "* " = all access > " *" = all access > 2) General clean-up and simplification > 3) NOT-BACKWARDS COMPATIBLE > The code currently handled spaces in an asymmetric way. The code splits the > ACL string on a single space, but limits the resulting array to a size of > two. So, as long as there are no spaces in the user names section, it works > fine, but any spaces subsequent to that did not matter. > "user1,user2,user3 group1, group2,group3" - works as expected > ["user1,user2,user3", "group1, group2,group3"] > "user1, user2,user3 group1,group2,group3" - Did not work as expected > ["user1,","user2,user3, group1, group2,group3"] > The submitted patch will split on all spaces and log a warning if there are > more than two elements. This enforces no spaces with the two comma-separated > lists. > Update: > Perhaps this can be expanded to use a semi-colon as the delimiter between > users and groups, so any interwoven spaces can simply be ignored. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HADOOP-12640) Code Review AccessControlList
[ https://issues.apache.org/jira/browse/HADOOP-12640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] BELUGA BEHR updated HADOOP-12640: - Description: After some confusion of my own, in particular with "mapreduce.job.acl-view-job," I have looked over the AccessControlList implementation and cleaned it up and clarified a few points. 1) I added tests to show that when including an asterisk in either the username or the group field, it overrides everything and allows all access. "user1,user2,user3 *" = all access "* group1,group2" = all access "* *" = all access "* " = all access " *" = all access 2) General clean-up and simplification 3) NOT-BACKWARDS COMPATIBLE The code currently handled spaces in an asymmetric way. The code splits the ACL string on a single space, but limits the resulting array to a size of two. So, as long as there are no spaces in the user names section, it works fine, but any spaces subsequent to that did not matter. "user1,user2,user3 group1, group2,group3" - works as expected ["user1,user2,user3", "group1, group2,group3"] "user1, user2,user3 group1,group2,group3" - Did not work as expected ["user1,","user2,user3, group1, group2,group3"] The submitted patch will split on all spaces and log a warning if there are more than two elements. This enforces no spaces with the two comma-separated lists. Update: Perhaps this can be expanded to use a semi-colon as the delimiter between users and groups, so any interwoven spaces can simply be ignored. was: After some confusion of my own, in particular with "mapreduce.job.acl-view-job," I have looked over the AccessControlList implementation and cleaned it up and clarified a few points. 1) I added tests to show that when including an asterisk in either the username or the group field, it overrides everything and allows all access. "user1,user2,user3 *" = all access "* group1,group2" = all access "* *" = all access "* " = all access " *" = all access 2) General clean-up and simplification 3) NOT-BACKWARDS COMPATIBLE The code currently handled spaces in an asymmetric way. The code splits the ACL string on a single space, but limits the resulting array to a size of two. So, as long as there are no spaces in the user names section, it works fine, but any spaces subsequent to that did not matter. "user1,user2,user3 group1, group2,group3" - works as expected ["user1,user2,user3", "group1, group2,group3"] "user1, user2,user3 group1,group2,group3" - Did not work as expected ["user1,","user2,user3, group1, group2,group3"] The submitted patch will split on all spaces and log a warning if there are more than two elements. This enforces no spaces with the two comma-separated lists. > Code Review AccessControlList > - > > Key: HADOOP-12640 > URL: https://issues.apache.org/jira/browse/HADOOP-12640 > Project: Hadoop Common > Issue Type: Improvement > Components: security >Affects Versions: 2.7.1 >Reporter: BELUGA BEHR >Priority: Minor > Attachments: AccessControlList.patch, TestAccessControlList.path > > > After some confusion of my own, in particular with > "mapreduce.job.acl-view-job," I have looked over the AccessControlList > implementation and cleaned it up and clarified a few points. > 1) I added tests to show that when including an asterisk in either the > username or the group field, it overrides everything and allows all access. > "user1,user2,user3 *" = all access > "* group1,group2" = all access > "* *" = all access > "* " = all access > " *" = all access > 2) General clean-up and simplification > 3) NOT-BACKWARDS COMPATIBLE > The code currently handled spaces in an asymmetric way. The code splits the > ACL string on a single space, but limits the resulting array to a size of > two. So, as long as there are no spaces in the user names section, it works > fine, but any spaces subsequent to that did not matter. > "user1,user2,user3 group1, group2,group3" - works as expected > ["user1,user2,user3", "group1, group2,group3"] > "user1, user2,user3 group1,group2,group3" - Did not work as expected > ["user1,","user2,user3, group1, group2,group3"] > The submitted patch will split on all spaces and log a warning if there are > more than two elements. This enforces no spaces with the two comma-separated > lists. > Update: > Perhaps this can be expanded to use a semi-colon as the delimiter between > users and groups, so any interwoven spaces can simply be ignored. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HADOOP-12640) Code Review AccessControlList
[ https://issues.apache.org/jira/browse/HADOOP-12640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] BELUGA BEHR updated HADOOP-12640: - Attachment: TestAccessControlList.path AccessControlList.patch > Code Review AccessControlList > - > > Key: HADOOP-12640 > URL: https://issues.apache.org/jira/browse/HADOOP-12640 > Project: Hadoop Common > Issue Type: Improvement > Components: security >Affects Versions: 2.7.1 >Reporter: BELUGA BEHR >Priority: Minor > Attachments: AccessControlList.patch, TestAccessControlList.path > > > After some confusion of my own, in particular with > "mapreduce.job.acl-view-job," I have looked over the AccessControlList > implementation and cleaned it up and clarified a few points. > 1) I added tests to show that when including an asterisk in either the > username or the group field, it overrides everything and allows all access. > "user1,user2,user3 *" = all access > "* group1,group2" = all access > "* *" = all access > "* " = all access > " *" = all access > 2) General clean-up and simplification > 3) NOT-BACKWARDS COMPATIBLE > The code currently handled spaces in an asymmetric way. The code splits the > ACL string on a single space, but limits the resulting array to a size of > two. So, as long as there are no spaces in the user names section, it works > fine, but any spaces subsequent to that did not matter. > "user1,user2,user3 group1, group2,group3" - works as expected > ["user1,user2,user3", "group1, group2,group3"] > "user1, user2,user3 group1,group2,group3" - Did not work as expected > ["user1,","user2,user3, group1, group2,group3"] > The submitted patch will split on all spaces and log a warning if there are > more than two elements. This enforces no spaces with the two comma-separated > lists. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
