[HDFS-8037] CheckAccess in WebHDFS silently accepts malformed FsActions parameters

• Type: Bug
• Status: Resolved
• Priority: Minor
• Resolution: Fixed
• Affects Version/s: 2.6.0
• Fix Version/s: 2.8.0, 3.0.0-alpha1
• Component/s: webhdfs
• Labels: easyfix newbie
• Hadoop Flags: Reviewed
• Assignee: Walter Su
• Reporter: Jake Low
• Created: 01/Apr/15 00:55
• Updated: 30/Aug/16 01:37
• Resolved: 07/May/15 22:26

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.

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"
  }
}

But if we instead request "r-w" access, the call appears to succeed:

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

As I see it, the fix would be to change the regex pattern in FsActionParam to something like "[r-][w-][x-]".