Mailing-List: contact common-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Date: Fri, 6 Oct 2017 11:42:00 +0000 (UTC)
From: "Kannapiran Srinivasan (JIRA)" <jira@apache.org>
To: common-issues@hadoop.apache.org
Message-ID: <JIRA.13104258.1506077750000.288431.1507290120809@Atlassian.JIRA>
In-Reply-To: <JIRA.13104258.1506077750000@Atlassian.JIRA>
References: <JIRA.13104258.1506077750000@Atlassian.JIRA> <JIRA.13104258.1506077750795@jira-lw-us.apache.org>
Subject: [jira] [Commented] (HADOOP-14899) Restrict Access to setPermission
 operation when authorization is enabled in WASB
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
archived-at: Fri, 06 Oct 2017 11:42:05 -0000


    [ https://issues.apache.org/jira/browse/HADOOP-14899?page=3Dcom.atlassi=
an.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D16=
194481#comment-16194481 ]=20

Kannapiran Srinivasan commented on HADOOP-14899:
------------------------------------------------

[~stevel@apache.org] : I have updated the patch with following fixes
* L698: I think it is better to have a separate list defined for chmod allo=
wed users instead of using a common one for both chown and chmod. Because t=
his gives a flexibility to configure different set of allowed users for bot=
h chmod & chown. I have reverted the code back to use fs.azure.chown.allowe=
d.userlist for chown.
* L2916: Fixed
* L2980: Fixed
* L7971. chmod & chown should check against the current user not the actual=
User. actualUser is set in the context of impersonation. Earlier logic on s=
etPermission was wrongly checking the actualUser instead of currentUser. Ye=
s getCurrentUser should not be null during chmod / chown calls irrespective=
 of impersonation enabled or not
* L3055. Cached the user lists (chown, chmod & daemon) during the init & en=
abled set of helper methods for tests to update them during test runs
* Refactoring is done on the testcases as mentioned in the comment=C2=A0

Apart from this I have fixed testcases related to setOwner (testSetOwnerThr=
owsForUnauthorisedUsers, testSetOwnerFailsForIllegalSetup, testSetOwnerThro=
wsForUnauthorisedUsers & testSetOwnerSucceedsForAnyUserWhenWildCardIsSpecif=
ied)

All the tests have passed in hadoop-azure in both secure and unsecure mode.=
 Tested against storage account in South India

> Restrict Access to setPermission operation when authorization is enabled =
in WASB
> -------------------------------------------------------------------------=
-------
>
>                 Key: HADOOP-14899
>                 URL: https://issues.apache.org/jira/browse/HADOOP-14899
>             Project: Hadoop Common
>          Issue Type: Sub-task
>          Components: fs/azure
>            Reporter: Kannapiran Srinivasan
>            Assignee: Kannapiran Srinivasan
>              Labels: fs, secure, wasb
>         Attachments: HADOOP-14899-001.patch, HADOOP-14899-002.patch, HADO=
OP-14899-003.patch, HADOOP-14899-004.patch
>
>
> In case of authorization enabled Wasb clusters, we need to restrict setti=
ng permissions on files or folders to owner or list of privileged users.
> Currently in the WASB implementation even when authorization is enabled t=
here is no check happens while doing setPermission call. In this JIRA we wo=
uld like to add the check on the setPermission call in NativeAzureFileSyste=
m implementation so that only owner or the privileged list of users or daem=
on users can change the permissions of files/folders


--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-issues-help@hadoop.apache.org