[
https://issues.apache.org/jira/browse/HDFS-8037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14390194#comment-14390194
]
Walter Su commented on HDFS-8037:
---------------------------------
{{fsaction=r-w}} doesn't match POSIX style, but it matches regex
{{"\[rwx-\]\{3\}"}}.
Currently, The behaviour on the server side:
The request passes argument checks in {{FsActionParam.parse(.)}}, so the server
doesn't return {{IllegalArgumentException}}.
In {{FsAction.getFsAction(..)}}, {{r-w}} doesn't match any enum types, so the
function returns {{null}}.
{{FSPermissionChecker.checkPermission(..)}} will *NOT* throw
{{AccessControlException}} if {{access==null}}
Currently, The behaviour on the client side:
{code}
curl -X GET
"http://localhost:50070/webhdfs/v1/myfile?op=CHECKACCESS&user.name=nobody&fsaction=r-w";
{code}
is the same as
{code}
curl -X GET
"http://localhost:50070/webhdfs/v1/myfile?op=CHECKACCESS&user.name=nobody&fsaction=null";
{code}
is the same as
{code}
curl -X GET
"http://localhost:50070/webhdfs/v1/myfile?op=CHECKACCESS&user.name=nobody";
{code}
This behaviour is not right, we should fix it. It should be like the filesystem
in linux
{code}
# chmod rxw /tmp/tmpfile
chmod: invalid mode: `rxw'
Try `chmod --help' for more information.
{code}
*In conclustion*
We should change the regex pattern in {{FsActionParam}} to
{{"\[r-\]\[w-\]\[x-\]"}} as [~jake-low] proposed, and the server should throws
{{IllegalArgumentException}} if the argument doesn't match POSIX style.
> WebHDFS: CheckAccess silently accepts certain malformed FsActions
> -----------------------------------------------------------------
>
> Key: HDFS-8037
> URL: https://issues.apache.org/jira/browse/HDFS-8037
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: webhdfs
> Affects Versions: 2.6.0
> Reporter: Jake Low
> Assignee: Walter Su
> Priority: Minor
> Labels: easyfix, newbie
>
> WebHDFS's {{CHECKACCESS}} operation accepts a parameter called {{fsaction}},
> which represents the type(s) of access to check for.
> According to the documentation, and also the source code, the domain of
> {{fsaction}} is the set of strings matched by the regex {{"\[rwx-\]{3\}"}}.
> This domain is wider than the set of valid {{FsAction}} objects, because it
> doesn't guarantee sensible ordering of access types. For example, the strings
> {{"rxw"}} and {{"--r"}} are valid {{fsaction}} parameter values, but don't
> correspond to valid {{FsAction}} instances.
> The result is that WebHDFS silently accepts {{fsaction}} parameter values
> which don't match any valid {{FsAction}} instance, but doesn't actually
> perform any permissions checking in this case.
> For example, here's a {{CHECKACCESS}} call where we request {{"rw-"}} access
> on a file which we only have permission to read and execute. It raises an
> exception, as it should.
> {code:none}
> curl -i -X GET
> "http://localhost:50070/webhdfs/v1/myfile?op=CHECKACCESS&user.name=nobody&fsaction=r-x";
> HTTP/1.1 403 Forbidden
> Content-Type: application/json
> {
> "RemoteException": {
> "exception": "AccessControlException",
> "javaClassName": "org.apache.hadoop.security.AccessControlException",
> "message": "Permission denied: user=nobody, access=READ_WRITE,
> inode=\"\/myfile\":root:supergroup:drwxr-xr-x"
> }
> }
> {code}
> But if we instead request {{"r-w"}} access, the call appears to succeed:
> {code:none}
> curl -i -X GET
> "http://localhost:50070/webhdfs/v1/myfile?op=CHECKACCESS&user.name=nobody&fsaction=r-w";
> HTTP/1.1 200 OK
> Content-Length: 0
> {code}
> As I see it, the fix would be to change the regex pattern in
> {{FsActionParam}} to something like {{"\[r-\]\[w-\]\[x-\]"}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
