[
https://issues.apache.org/jira/browse/FALCON-1649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15046479#comment-15046479
]
sandeep samudrala commented on FALCON-1649:
-------------------------------------------
Pallavi Rao added a comment - 3 days ago
Have never been in favor of having 777 permission even for staging dir. Anyone
can accidentally delete all dirs under it and I believe that is Peeyush
Bishnoi's concern too.
But, I understand and appreciate the problem Balu Vellanki is trying to solve.
If staging dir is in user space, Falcon won't have permission to write to it.
If staging is in Falcon space (as is now), all users will need to be given
permission to it.
Tricky... Allow me to propose a sub-optimal solution, yet better than a
permanent 777 .
Let "falcon" be the owner of <staging_dir>/falcon/workflows/
{feed,process} with 755 permission. When "user1" schedules "entity1", we do the
following:
1. Change the permission of <staging_dir>/falcon/workflows/{feed,process}
to 777 as "falcon".
2. Create "entity1" directory under it as "user1" with default permission
3. Change back permission of <staging_dir>/falcon/workflows/
{feed,process} to 755.
4. Create artifacts as "user1" under
<staging_dir>/falcon/workflows/{feed,process}
/entity1
When 2 users absolutely simultaneously try to schedule 2 entities, there might
be a small window (when perm is changed back to 755), when this will fail. In
such a case, the user will have to retry. We just have to return the right
message.
> 777 permission issue on staging directory and on subdirectory
> --------------------------------------------------------------
>
> Key: FALCON-1649
> URL: https://issues.apache.org/jira/browse/FALCON-1649
> Project: Falcon
> Issue Type: Bug
> Reporter: sandeep samudrala
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
