[jira] [Created] (HDFS-8037) WebHDFS: CheckAccess silently accepts certain malformed FsActions

["Jake Low (JIRA)" <ji...@apache.org>]

Jake Low created HDFS-8037:
------------------------------

             Summary: 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
            Priority: Minor


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 -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)