Apache
/
hadoop
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

HDFS-9552. Document types of permission checks performed for HDFS operations. Contributed by Chris Nauroth.

This commit is contained in:
cnauroth 2015-12-17 10:43:48 -08:00
parent 72a3f649e4
commit 724e71f63b
2 changed files with 61 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt
View File

@ -1770,6 +1770,9 @@ Release 2.8.0 - UNRELEASED
HDFS-9557. Reduce object allocation in PB conversion
(Daryn Sharp via cnauroth)
HDFS-9552. Document types of permission checks performed for HDFS
operations. (cnauroth)
OPTIMIZATIONS
HDFS-8026. Trace FSOutputSummer#writeChecksumChunks rather than

58
hadoop-hdfs-project/hadoop-hdfs/src/site/markdown/HdfsPermissionsGuide.md
View File

@ -19,6 +19,7 @@ HDFS Permissions Guide
* [Overview](#Overview)
* [User Identity](#User_Identity)
* [Group Mapping](#Group_Mapping)
* [Permission Checks](#Permission_Checks)
* [Understanding the Implementation](#Understanding_the_Implementation)
* [Changes to the File System API](#Changes_to_the_File_System_API)
* [Changes to the Application Shell](#Changes_to_the_Application_Shell)
@ -81,6 +82,63 @@ For HDFS, the mapping of users to groups is performed on the NameNode. Thus, the
Note that HDFS stores the user and group of a file or directory as strings; there is no conversion from user and group identity numbers as is conventional in Unix.
Permission Checks
-----------------
Each HDFS operation demands that the user has specific permissions (some combination of READ, WRITE and EXECUTE), granted through file ownership, group membership or the other permissions. An operation may perform permission checks at multiple components of the path, not only the final component. Additionally, some operations depend on a check of the owner of a path.
All operations require traversal access. Traversal access demands the EXECUTE permission on all existing components of the path, except for the final path component. For example, for any operation accessing `/foo/bar/baz`, the caller must have EXECUTE permission on `/`, `/foo` and `/foo/bar`.
The following table describes the permission checks performed by HDFS for each component of the path.
* **Ownership:** Whether or not to check if the caller is the owner of the path. Typically, operations that change the ownership or permission metadata demand that the caller is the owner.
* **Parent:** The parent directory of the requested path. For example, for the path `/foo/bar/baz`, the parent is `/foo/bar`.
* **Ancestor:** The last **existing** component of the requested path. For example, for the path `/foo/bar/baz`, the ancestor path is `/foo/bar` if `/foo/bar` exists. The ancestor path is `/foo` if `/foo` exists but `/foo/bar` does not exist.
* **Final:** The final component of the requested path. For example, for the path `/foo/bar/baz`, the final path component is `/foo/bar/baz`.
* **Sub-tree:** For a path that is a directory, the directory itself and all of its child sub-directories, recursively. For example, for the path `/foo/bar/baz`, which has 2 sub-directories named `buz` and `boo`, the sub-tree is `/foo/bar/baz`, `/foo/bar/baz/buz` and `/foo/bar/baz/boo`.
Operation | Ownership | Parent | Ancestor | Final | Sub-tree
--------------------- | --------- | -------------- | ------------------- | ----------------------------------- | --------
append | NO | N/A | N/A | WRITE | N/A
concat | NO [2] | WRITE (sources) | N/A | READ (sources), WRITE (destination) | N/A
create | NO | N/A | WRITE | WRITE [1] | N/A
createSnapshot | YES | N/A | N/A | N/A | N/A
delete | NO [2] | WRITE | N/A | N/A | READ, WRITE, EXECUTE
deleteSnapshot | YES | N/A | N/A | N/A | N/A
getAclStatus | NO | N/A | N/A | N/A | N/A
getBlockLocations | NO | N/A | N/A | READ | N/A
getContentSummary | NO | N/A | N/A | N/A | READ, EXECUTE
getFileInfo | NO | N/A | N/A | N/A | N/A
getFileLinkInfo | NO | N/A | N/A | N/A | N/A
getLinkTarget | NO | N/A | N/A | N/A | N/A
getListing | NO | N/A | N/A | READ, EXECUTE | N/A
getSnapshotDiffReport | NO | N/A | N/A | READ | READ
getStoragePolicy | NO | N/A | N/A | READ | N/A
getXAttrs | NO | N/A | N/A | READ | N/A
listXAttrs | NO | EXECUTE | N/A | N/A | N/A
mkdirs | NO | N/A | WRITE | N/A | N/A
modifyAclEntries | YES | N/A | N/A | N/A | N/A
removeAcl | YES | N/A | N/A | N/A | N/A
removeAclEntries | YES | N/A | N/A | N/A | N/A
removeDefaultAcl | YES | N/A | N/A | N/A | N/A
removeXAttr | NO [2] | N/A | N/A | WRITE | N/A
rename | NO [2] | WRITE (source) | WRITE (destination) | N/A | N/A
renameSnapshot | YES | N/A | N/A | N/A | N/A
setAcl | YES | N/A | N/A | N/A | N/A
setOwner | YES [3] | N/A | N/A | N/A | N/A
setPermission | YES | N/A | N/A | N/A | N/A
setReplication | NO | N/A | N/A | WRITE | N/A
setStoragePolicy | NO | N/A | N/A | WRITE | N/A
setTimes | NO | N/A | N/A | WRITE | N/A
setXAttr | NO [2] | N/A | N/A | WRITE | N/A
truncate | NO | N/A | N/A | WRITE | N/A
[1] WRITE access on the final path component during `create` is only required if the call uses the overwrite option and there is an existing file at the path.
[2] Any operation that checks WRITE permission on the parent directory also checks ownership if the [sticky bit](#Overview) is set.
[3] Calling `setOwner` to change the user that owns a file requires [HDFS super-user](#The_Super-User) access. HDFS super-user access is not required to change the group, but the caller must be a member of the specified group.
Understanding the Implementation
--------------------------------