[
https://issues.apache.org/jira/browse/HADOOP-4106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12631586#action_12631586
]
Allen Wittenauer commented on HADOOP-4106:
------------------------------------------
Now that I think about it, access() may not be necessary for chown()/chmod().
In particular, I'm thinking of a bug that happened in Solaris cpio (or was it
pax?) eons ago where a user had a privilege assigned that allowed that user to
chown() files. But that user couldn't actually read the files. So doing a raw
chown() with no access check was the right thing to do.
If Hadoop were to mature enough to have a role system, doing access() followed
by chown()/chmod() would be the wrong thing to do.
So, yes, I think it is ok to do chown()/chmod() without access() and just let
the EPERM error or whatever Hadoop is throwing back to the user.
Of course, this begs the question about what FUSE will do under roles, but
that's a different discussion for a different day. :)
> add time, permission and user attribute support to fuse-dfs
> -----------------------------------------------------------
>
> Key: HADOOP-4106
> URL: https://issues.apache.org/jira/browse/HADOOP-4106
> Project: Hadoop Core
> Issue Type: New Feature
> Components: contrib/fuse-dfs
> Reporter: Pete Wyckoff
> Assignee: Pete Wyckoff
> Fix For: 0.19.0
>
> Attachments: HADOOP-4106.txt, HADOOP-4106.txt, HADOOP-4106.txt,
> HADOOP-4106.txt
>
>
> add:
> dfs_chown
> dfs_utime
> dfs_chmod
> Change open to have its own FS on writes (should we do this on reads too??)
> and use it for writes and disconnect when closing the file
> Chane mkdir to open the FS itself and then close it
> also added comments for dfs_access (which needs FileSystem support/libhdfs
> support) and I added the dfs_symlink and truncate since these 3 are the only
> 3 things left as far as functionality.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
