hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Varada Hemeswari (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-14913) Sticky bit implementation for Rename operation in Azure fs
Date Tue, 10 Oct 2017 14:31:00 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-14913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16198739#comment-16198739
] 

Varada Hemeswari commented on HADOOP-14913:
-------------------------------------------

[~stevel@apache.org], Thanks for the review.
I have addressed your comments of moving the decision of exceptions thrown to rename instead
of stickybit check.
However, for some of the other comments regarding FNFE and returning 'false' in Azure Filesystem,
the contract says, 
{code}
<property>
    <name>fs.contract.rename-returns-false-if-source-missing</name>
    <value>true</value>
  </property>
{code}
So accordingly, instead of throwing FNFE, I am returning false. This is same behaviour as
Auth-not-enabled case too in the rename implementation.
I agree that the exception shouldnt be swallowed for apps to know the reason for failure,
but this has nothing to do with sticky bit checks. I am simply retaining existing semantics.

Similarly 'rename' functionality in Auth-not-enabled case is fully tested by contract test
for Rename.
However, TestNativeAzureFileSystemAuthorization concentrates only on auth behaviour for all
fs calls. Since the expectation is all the implementation for fs call is same except for additional
auth calls and stickybit checks being made, protected by azureAuthorization flag(so that auth-not-enabled
cases are undisturbed at any point).

Considering this risk is not much higher. I agree about the 'delete' risk since we introduced
partial delete which is huge change.

I tried to add all possible test cases related to changes made in this patch for sticky bit
and moving auth check calls in Rename. I have also added tests for src not existing use case
since stickybit check has to retain this behaviour.

If your concern is auth enabling is not testing whole paths of all fs calls, may be we should
consider having contract test runs with auth enabled cases. However it must be a seperate
endeavour unrelated to this change('Rename') alone.


> Sticky bit implementation for Rename operation in Azure fs
> ----------------------------------------------------------
>
>                 Key: HADOOP-14913
>                 URL: https://issues.apache.org/jira/browse/HADOOP-14913
>             Project: Hadoop Common
>          Issue Type: New Feature
>          Components: fs, fs/azure
>            Reporter: Varada Hemeswari
>            Assignee: Varada Hemeswari
>              Labels: azure, fs, secure
>         Attachments: HADOOP-14193.001.patch, HADOOP-14193.002.patch, HADOOP-14913-003.patch
>
>
> When authorization is enabled in WASB filesystem, there is a need for stickybit in cases
where multiple users can create files under a shared directory. This additional check for
sticky bit is reqired since any user can delete/rename another user's file because the parent
has WRITE permission for all users.
> The purpose of this jira is to implement sticky bit equivalent for 'rename' call when
authorization is enabled.



--
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


Mime
View raw message