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

[[email protected]], 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: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to