Mailing-List: contact core-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: core-dev@hadoop.apache.org
Message-ID: <1283962711.1221001785055.JavaMail.jira@brutus>
Date: Tue, 9 Sep 2008 16:09:45 -0700 (PDT)
From: "Pete Wyckoff (JIRA)" <jira@apache.org>
To: core-dev@hadoop.apache.org
Subject: [jira] Commented: (HADOOP-4108) FileSystem support for POSIX access
 method
In-Reply-To: <37364288.1220846564500.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/HADOOP-4108?page=3Dcom.atlassia=
n.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D126=
29650#action_12629650 ]=20

Pete Wyckoff commented on HADOOP-4108:
--------------------------------------

I'm not sure I did a good job describing the functionality. It should do a =
getFileStatus but then look at the current user/groups and have the logic t=
o decide if the user is allowed to access the file.  Really api request sho=
uld have been

{code}
// given the permissions/groups/owner in FileStatus and the mode, output wh=
at the passed in user is allowed to do to the file
int access(FileStatus f, int mode, String uid, String groups[]);
{code}

but, as you point out, the client side can implement this itself.   But, it=
 does have to loop through the groups and such know the Hadoop permission l=
ogic.


> 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
>
> From man access:
> {code}
>  int access(const char *pathname, int mode);
> {code}
> DESCRIPTION
>        access  checks  whether  the process would be allowed to read, wri=
te or test for existence of the file (or other file system object) whose na=
me is pathname.  If pathname is a symbolic link permissions of the file ref=
erred 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 h=
as read, write and execute permissions, respectively.  F_OK just requests c=
hecking for the existence of the file.
>        The tests depend on the permissions of the directories occurring i=
n the path to the file, as given in pathname, and on the permissions of dir=
ectories and files referred to by symbolic links encountered on the way.
>        The check is done with the process=C3=A2s real uid and gid, rather=
 than with the effective ids as is done when actually attempting an operati=
on.  This is to allow set-UID  programs  to
>        easily determine the invoking user=C3=A2s authority.
>        Only  access  bits  are checked, not the file type or contents.  T=
herefore, 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 stil=
l fail.
>        If the process has appropriate privileges, an implementation may i=
ndicate success for X_OK even if none of the execute file permission bits a=
re 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.

--=20
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.