概述
hadoop分布式檔案系統實現了乙個和posix系統類似的檔案和目錄的許可權模型。每個檔案和目錄有乙個所有者(owner)和乙個組(group)。檔案或目錄對其所有者、同組的其他使用者以及所有其他使用者分別有著不同的許可權。對檔案而言，當讀取這個檔案時需要有r許可權，當寫入或者追加到檔案時需要有w許可權。對目錄而言，當列出目錄內容時需要具有r許可權，當新建或刪除子檔案或子目錄時需要有w許可權，當訪問目錄的子節點時需要有x許可權。不同於posix模型，hdfs許可權模型中的檔案沒有sticky，setuid或setgid位，因為這裡沒有可執行檔案的概念。為了簡單起見，這裡也沒有目錄的sticky，setuid或setgid位。總的來說，檔案或目錄的許可權就是它的模式(mode)。hdfs採用了unix表示和顯示模式的習慣，包括使用八進位制數來表示許可權。當新建乙個檔案或目錄，它的所有者即客戶程序的使用者，它的所屬組是父目錄的組(bsd的規定)。
每個訪問hdfs的使用者程序的標識分為兩個部分，分別是使用者名稱和組名列表。每次使用者程序訪問乙個檔案或目錄foo，hdfs都要對其進行許可權檢查，
如果使用者即foo的所有者，則檢查所有者的訪問許可權；
如果foo關聯的組在組名列表**現，則檢查組使用者的訪問許可權；
否則檢查foo其他使用者的訪問許可權。
如果許可權檢查失敗，則客戶的操作會失敗。
使用者身份
在這個版本的hadoop中，客戶端使用者身份是通過宿主作業系統給出。對類unix系統來說，
使用者名稱等於`whoami`；
組列表等於`bash -c groups`。
將來會增加其他的方式來確定使用者身份(比如kerberos、ldap等)。期待用上文中提到的第一種方式來防止乙個使用者假冒另乙個使用者是不現實的。這種使用者身份識別機制結合許可權模型允許乙個協作團體以一種有組織的形式共享檔案系統中的資源。
不管怎樣，使用者身份機制對hdfs本身來說只是外部特性。hdfs並不提供建立使用者身份、建立組或處理使用者憑證等功能。
理解系統的實現
每次檔案或目錄操作都傳遞完整的路徑名給name node，每乙個操作都會對此路徑做許可權檢查。客戶框架會隱式地將使用者身份和與name node的連線關聯起來，從而減少改變現有客戶端api的需求。經常會有這種情況，當對乙個檔案的某一操作成功後，之後同樣的操作卻會失敗，這是因為檔案或路徑上的某些目錄已經不復存在了。比如，客戶端首先開始讀乙個檔案，它向name node發出乙個請求以獲取檔案第乙個資料塊的位置。但接下去的獲取其他資料塊的第二個請求可能會失敗。另一方面，刪除乙個檔案並不會撤銷客戶端已經獲得的對檔案資料塊的訪問許可權。而許可權管理能使得客戶端對乙個檔案的訪問許可在兩次請求之間被收回。重複一下，許可權的改變並不會撤銷當前客戶端對檔案資料塊的訪問許可。
map-reduce框架通過傳遞字串來指派使用者身份，沒有做其他特別的安全方面的考慮。檔案或目錄的所有者和組屬性是以字串的形式儲存，而不是像傳統的unix方式轉換為使用者和組的數字id。
這個發行版本的許可權管理特性並不需要改變data node的任何行為。data node上的資料塊上並沒有任何hadoop所有者或許可權等關聯屬性。
檔案系統api變更
如果許可權檢查失敗，所有使用乙個路徑引數的方法都可能丟擲accesscontrolexception異常。
新增方法：
public fsdataoutputstream create(path f, fspermission permission, boolean overwrite, int buffersize, short replication, long blocksize, progressable progress) throws ioexception；
public boolean mkdirs(path f, fspermission permission) throws ioexception；
public void setpermission(path p, fspermission permission) throws ioexception；
public void setowner(path p, string username, string groupname) throws ioexception；
public filestatus getfilestatus(path f) throws ioexception； 也會返回路徑關聯的所有者、組和模式屬性。
新建檔案或目錄的模式受配置引數umask的約束。當使用之前的 create(path, …) 方法(沒有指定許可權引數)時，新檔案的模式是666 & ^umask。當使用新的 create(path, permission, …) 方法(指定了許可權引數p)時，新檔案的模式是p & ^umask & 666。當使用先前的 mkdirs(path) 方法(沒有指定 許可權引數)新建乙個目錄時，新目錄的模式是777 & ^umask。當使用新的 mkdirs(path, permission ) 方法(指定了許可權引數p)新建乙個目錄時，新目錄的模式是p & ^umask & 777。
shell命令變更
新增操作：
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伺服器
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,webgroupweb伺服器使用的使用者名稱。如果將這個引數設定為超級使用者的名稱，則所有web客戶就可以看到所有的資訊。如果將這個引數設定為乙個不使用的使用者，則web客戶就只能訪問到「other」許可權可訪問的資源了。額外的組可以加在後面，形成乙個用逗號分隔的列表。dfs.permissions.supergroup = supergroup超級使用者的組名。dfs.upgrade.permission = 777公升級時的初始模式。檔案永不會被設定x許可權。在配置檔案中，可以使用十進位制數51110。dfs.umask = 022umask引數在建立檔案和目錄時使用。在配置檔案中，可以使用十進位制數1810。
hdfs user 連線 HDFS許可權管理使用者指南
hdfs許可權管理使用者指南 概述hadoop分布式檔案系統實現了乙個和posix系統類似的檔案和目錄的許可權模型。每個檔案和目錄有乙個所有者 owner 和乙個組 group 檔案或目錄對其所有者 同組的其他使用者以及所有其他使用者分別有著不同的許可權。對檔案而言，當讀取這個檔案時需要有r許可權，...
Linux 鑑權連線 mongoDB
首先確定linux上mongodb的版本，社群版還是企業版，並且需要了解資料庫連線過程中是否開啟了鑑權。首先進入mongo模式，一般情況下mongo應該做軟連線到系統啟動項中。use admin切換到admin資料庫 db.auth username password 鑑權連線資料庫 此時返回值為1...
HDFS檔案系統的基本操作 Hadoop權威指南
1.1.1 基本操作幫助 hadoop fs help1.1.2 在hdfs上建立如下目錄 命令 hadoop fs mkdir p usr local hadoop input1 1.1.3 將檔案從xujing01複製到hdfs usr local hadoop input1 目錄 命令 had...