hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jake Low (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HDFS-8037) WebHDFS: CheckAccess silently accepts certain malformed FsActions
Date Wed, 01 Apr 2015 01:25:53 GMT

     [ https://issues.apache.org/jira/browse/HDFS-8037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Jake Low updated HDFS-8037:
---------------------------
    Description: 
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-\]"}}.

  was:
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-\]"}}.


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

Mime
View raw message