**：
hadoop分布式檔案系統實現了乙個和posix系統類似的檔案和目錄的許可權模型。每個檔案和目錄有乙個所有者（owner）和乙個組（group）。檔案或目錄對其所有者、同組的其他使用者以及所有其他使用者分別有著不同的許可權。對檔案而言，當讀取這個檔案時需要有r許可權，當寫入或者追加到檔案時需要有w許可權。對目錄而言，當列出目錄內容時需要具有r許可權，當新建或刪除子檔案或子目錄時需要有w許可權，當訪問目錄的子節點時需要有x許可權。不同於posix模型，hdfs許可權模型中的檔案沒有sticky，setuid或setgid位，因為這裡沒有可執行檔案的概念。為了簡單起見，這裡也沒有目錄的sticky，setuid或setgid位。總的來說，檔案或目錄的許可權就是它的模式（mode）。hdfs採用了unix表示和顯示模式的習慣，包括使用八進位制數來表示許可權。當新建乙個檔案或目錄，它的所有者即客戶程序的使用者，它的所屬組是父目錄的組（bsd的規定）。
每個訪問hdfs的使用者程序的標識分為兩個部分，分別是使用者名稱和組名列表。每次使用者程序訪問乙個檔案或目錄foo，hdfs都要對其進行許可權檢查，
如果許可權檢查失敗，則客戶的操作會失敗。
在這個版本的hadoop中，客戶端使用者身份是通過宿主作業系統給出。對類unix系統來說，
將來會增加其他的方式來確定使用者身份（比如kerberos、ldap等）。期待用上文中提到的第一種方式來防止乙個使用者假冒另乙個使用者是不現實的。這種使用者身份識別機制結合許可權模型允許乙個協作團體以一種有組織的形式共享檔案系統中的資源。
不管怎樣，使用者身份機制對hdfs本身來說只是外部特性。hdfs並不提供建立使用者身份、建立組或處理使用者憑證等功能。
每次檔案或目錄操作都傳遞完整的路徑名給name node，每乙個操作都會對此路徑做許可權檢查。客戶框架會隱式地將使用者身份和與name node的連線關聯起來，從而減少改變現有客戶端api的需求。經常會有這種情況，當對乙個檔案的某一操作成功後，之後同樣的操作卻會失敗，這是因為檔案或路徑上的某些目錄已經不復存在了。比如，客戶端首先開始讀乙個檔案，它向name node發出乙個請求以獲取檔案第乙個資料塊的位置。但接下去的獲取其他資料塊的第二個請求可能會失敗。另一方面，刪除乙個檔案並不會撤銷客戶端已經獲得的對檔案資料塊的訪問許可權。而許可權管理能使得客戶端對乙個檔案的訪問許可在兩次請求之間被收回。重複一下，許可權的改變並不會撤銷當前客戶端對檔案資料塊的訪問許可。
map-reduce框架通過傳遞字串來指派使用者身份，沒有做其他特別的安全方面的考慮。檔案或目錄的所有者和組屬性是以字串的形式儲存，而不是像傳統的unix方式轉換為使用者和組的數字id。
這個發行版本的許可權管理特性並不需要改變data node的任何行為。data node上的資料塊上並沒有任何hadoop所有者或許可權等關聯屬性。
如果許可權檢查失敗，所有使用乙個路徑引數的方法都可能丟擲accesscontrolexception異常。
新增方法：
新建檔案或目錄的模式受配置引數umask的約束。當使用之前的 create(path, …) 方法（沒有指定許可權引數）時，新檔案的模式是666 & ^umask。當使用新的 create(path,
permission
, …) 方法（指定了許可權引數p）時，新檔案的模式是p & ^umask & 666。當使用先前的 mkdirs(path) 方法（沒有指定 許可權引數）新建乙個目錄時，新目錄的模式是777 & ^umask。當使用新的 mkdirs(path,
permission
) 方法（指定了許可權引數p）新建乙個目錄時，新目錄的模式是p & ^umask & 777。
新增操作：
chmod [-r]
mode file …
只有檔案的所有者或者超級使用者才有許可權改變檔案模式。
chgrp [-r]
group file …
使用 chgrp命令的使用者必須屬於特定的組且是檔案的所有者，或者使用者是超級使用者。
chown [-r]
[owner][:[group]] file …
檔案的所有者的只能被超級使用者更改。
ls file …
lsr
file …
輸出格式做了調整以顯示所有者、組和模式。
超級使用者即執行name node程序的使用者。寬泛的講，如果你啟動了name node，你就是超級使用者。超級使用者幹任何事情，因為超級使用者能夠通過所有的許可權檢查。沒有永久記號保留誰過去是超級使用者；當name node開始執行時，程序自動判斷誰現在是超級使用者。hdfs的超級使用者不一定非得是name node主機上的超級使用者，也不需要所有的集群的超級使用者都是乙個。同樣的，在個人工作站上執行hdfs的實驗者，不需任何配置就已方便的成為了他的部署例項的超級使用者。
另外，管理員可以用配置引數指定一組特定的使用者，如果做了設定，這個組的成員也會是超級使用者。
web伺服器的身份是乙個可配置引數。name node並沒有真實使用者的概念，但是web伺服器表現地就像它具有管理員選定的使用者的身份（使用者名稱和組）一樣。除非這個選定的身份是超級使用者，否則會有名字空間中的一部分對web伺服器來說不可見。
如果集群在0.15版本的資料集（fsimage）上啟動，所有的檔案和目錄都有所有者o，組g，和模式m，這裡 o 和 g 分別是超級使用者的使用者標識和組名，m是乙個配置引數。
dfs.permissions = true
如果是
true，則開啟前文所述的許可權系統。如果是
false，許可權
檢查 就是關閉的，但是其他的行為沒有改變。這個配置引數的改變並不改變檔案或目錄的模式、所有者和組等資訊。
不管許可權模式是開還是關，
chmod，
chgrp 和
chown
總是 會檢查許可權。這些命令只有在許可權檢查背景下才有用，所以不會有相容性問題。這樣，這就能讓管理員在開啟常規的許可權檢查之前可以可靠地設定檔案的所有者和許可權。
dfs.web.ugi = webuser,webgroup
web伺服器使用的使用者名稱。如果將這個引數設定為超級使用者的名稱，則所有web客戶就可以看到所有的資訊。如果將這個引數設定為乙個不使用的使用者，則web客戶就只能訪問到「other」許可權可訪問的資源了。額外的組可以加在後面，形成乙個用逗號分隔的列表。
dfs.permissions.supergroup = supergroup
超級使用者的組名。
dfs.upgrade.permission = 777
公升級時的初始模式。檔案
永不會被設定
x許可權。在配置檔案中，可以使用十進位制數
51110。
dfs.umask = 022
umask引數在建立檔案和目錄時使用。在配置檔案中，可以使用十進位制數
1810。
hadoop分布式檔案系統(hdfs)允許管理員為每個目錄設定配額。 新建立的目錄沒有配額。 最大的配額是long.max_value。配額為1可以強制目錄保持為空。
目錄配額是對目錄樹上該目錄下的名字數量做硬性限制。如果建立檔案或目錄時超過了配額，該操作會失敗。重新命名不會改變該目錄的配額；如果重新命名操作會導致違反配額限制，該操作將會失敗。如果嘗試設定乙個配額而現有檔案數量已經超出了這個新配額，則設定失敗。
配額和fsimage保持一致。當啟動時，如果fsimage違反了某個配額限制（也許fsimage被偷偷改變了），則啟動失敗並生成錯誤報告。設定或刪除乙個配額會建立相應的日誌記錄。
下面的新命令或新選項是用於支援配額的。 前兩個是管理員命令。
hdfs user 連線 HDFS許可權管理使用者指南
概述 hadoop分布式檔案系統實現了乙個和posix系統類似的檔案和目錄的許可權模型。每個檔案和目錄有乙個所有者 owner 和乙個組 group 檔案或目錄對其所有者 同組的其他使用者以及所有其他使用者分別有著不同的許可權。對檔案而言，當讀取這個檔案時需要有r許可權，當寫入或者追加到檔案時需要有...
hdfs user 連線 HDFS許可權管理使用者指南
hdfs許可權管理使用者指南 概述hadoop分布式檔案系統實現了乙個和posix系統類似的檔案和目錄的許可權模型。每個檔案和目錄有乙個所有者 owner 和乙個組 group 檔案或目錄對其所有者 同組的其他使用者以及所有其他使用者分別有著不同的許可權。對檔案而言，當讀取這個檔案時需要有r許可權，...
cdh使用者許可權 cdh設定hdfs許可權
通常會把 root 或者需要的使用者新增到 supergroup組，但linux下預設是沒有supergroup組。linux下預設是沒有supergroup組的 hadoop x 994 hdfs,mapred,yarn cat etc group 檢視hdfs使用者的組是hadoop hdfs ...