[
https://issues.apache.org/jira/browse/HADOOP-4108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12631553#action_12631553
]
wyckoff edited comment on HADOOP-4108 at 9/16/08 2:15 PM:
---------------------------------------------------------------
Dhruba and I discussed this offline and here's what we would like to propose:
1. Add a private field superuser to FileStatus and ensure it is set in all the
FileStatus constructors (and FileStatus still doesn't have any logic pertaining
to a specific user - ie its still really a stat object)
2. Add the utility API: {code} FsAction access(FileStatus f) throws
IOException;{code} to FileSystem using the code Owen added to the JIRA.
FileSystems can override the access method and no need for a RPC as you are
passed in the FileStatus. Since this is computed on the client-side, the user
is known to the FS.
I think this incorporates all the discussed points.
was (Author: wyckoff):
Dhruba and I discussed this offline and here's what we would like to
propose:
1. Add a private field superuser to FileStatus and ensure it is set in all the
FileStatus constructors (and FileStatus still doesn't have any logic pertaining
to a specific user - ie its still really a stat object)
2. Add the utility API: {code} FsAction access(FileStatus f) throws
IOException;{code} to FileSystem using the code Owen added to the JIRA.
FileSystems can override the access method and no need for a RPC as you are
passed in the FileStatus. Since this is computed on the client-side, the user
is known to the FS.
> FileSystem support for POSIX access method
> ------------------------------------------
>
> Key: HADOOP-4108
> URL: https://issues.apache.org/jira/browse/HADOOP-4108
> Project: Hadoop Core
> Issue Type: New Feature
> Components: fs
> Reporter: Pete Wyckoff
> Assignee: Pete Wyckoff
>
> From man access:
> {code}
> int access(const char *pathname, int mode);
> {code}
> DESCRIPTION
> access checks whether the process would be allowed to read, write
> or test for existence of the file (or other file system object) whose name is
> pathname. If pathname is a symbolic link permissions of the file referred to
> by this symbolic link are tested.
> mode is a mask consisting of one or more of R_OK, W_OK, X_OK and F_OK.
> R_OK, W_OK and X_OK request checking whether the file exists and has
> read, write and execute permissions, respectively. F_OK just requests
> checking for the existence of the file.
> The tests depend on the permissions of the directories occurring in
> the path to the file, as given in pathname, and on the permissions of
> directories and files referred to by symbolic links encountered on the way.
> The check is done with the processâs real uid and gid, rather than
> with the effective ids as is done when actually attempting an operation.
> This is to allow set-UID programs to
> easily determine the invoking userâs authority.
> Only access bits are checked, not the file type or contents.
> Therefore, if a directory is found to be "writable," it probably means that
> files can be created in the directory,
> and not that the directory can be written as a file. Similarly, a DOS
> file may be found to be "executable," but the execve(2) call will still fail.
> If the process has appropriate privileges, an implementation may
> indicate success for X_OK even if none of the execute file permission bits
> are set.
> RETURN VALUE
> On success (all requested permissions granted), zero is returned. On
> error (at least one bit in mode asked for a permission that is denied, or
> some other error occurred), -1 is
> returned, and errno is set appropriately.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
