（這部分內容參考成品
之前在論壇看到乙個關於hdfs許可權的問題，當時無法回答該問題。無法回答並不意味著對hdfs許可權一無所知，而是不能準確完整的闡述hdfs許可權，因此決定系統地學習hdfs檔案許可權。hdfs的檔案和目錄許可權模型共享了posix（portable operating system inte***ce，可移植作業系統介面）模型的很多部分，比如每個檔案和目錄與乙個擁有者和組相關聯，檔案或者目錄對於擁有者、組內的其它使用者和組外的其它使用者有不同的許可權等。與posix模型不同的是，hdfs中的檔案沒有可執行檔案的概念，因而也沒有setuid和setgid，雖然目錄依然保留著可執行目錄的概念（x），但對於目錄也沒有setuid和setgid。貼上位（sticky bit）可以用在目錄上，用於阻止除超級使用者，目錄或檔案的擁有者外的任何刪除或移動目錄中的檔案，檔案上的貼上位不起作用。
當建立檔案或目錄時，擁有者為執行客戶端程序的使用者，組為父目錄所屬的組。每個訪問hdfs的客戶端程序有乙個由使用者姓名和組列表兩部分組的成標識，無論何時hdfs必須對由客戶端程序訪問的檔案或目錄進行許可權檢查，規則如下：
如果程序的使用者名稱匹配檔案或目錄的擁有者，那麼測試擁有者許可權
否則如果檔案或目錄所屬的組匹配組列表中任何組，那麼測試組許可權
否則測試其它許可權
如果許可權檢查失敗，則客戶端操作失敗。
從hadoop-0.22開始，hadoop支援兩種不同的操作模式以確定使用者，分別為******和kerberos具體使用哪個方式由引數hadoop.security.authentication設定，該引數位於core-site.xml檔案中，預設值為******。在******模式下，客戶端程序的身份由主機的作業系統確定，比如在類unix系統中，使用者名為命令whoami的輸出。在kerberos模式下，客戶端程序的身份由kerberos憑證確定，比如在乙個kerberized環境中，使用者可能使用kinit工具得到了乙個kerberos ticket-granting-ticket(tgt)且使用klist確定當前的principal。當對映乙個kerberosprincipal到hdfs的使用者名稱時，除了最主要的部分外其餘部分都被丟棄，比如乙個principal為todd/[email protected]，將對映為hdfs上的todd。無論哪種操作模式，對於hdfs來說使用者標識機制都是外部的，hdfs本身沒有建立使用者標，建立組或者處理使用者憑證的規定。
每個針對檔案或者目錄的操作都將全路徑名稱傳遞到namenode，然後對該路徑的每次操作都將應用許可權檢查。客戶端隱含地關聯使用者身份到namenode的連線，減少改變現存客戶端api的需要。總是存在這麼一種情景，當在乙個檔案上的操作成功後，當重複該操作時可能失敗，因為該檔案或者路徑中的某些目錄已經不再存在。例如，當客戶端第一次開始讀取乙個檔案時，它向namenode發出的第乙個請求來發現該檔案第乙個塊的位置，第二個尋找其他塊的請求可能失敗。另一方面，對於已經知道檔案塊的客戶端來說，刪除檔案不會取消訪問。通過新增許可權，客戶端對檔案的訪問在請求之間可能撤回，對於已經知道檔案塊的客戶端來說，改變許可權不會取消客戶端的訪問。
hdfs中超級使用者與通常熟悉的linux或unix中的root使用者不同，hdfs的超級使用者是與namenode程序有相同標示的使用者，更簡單易懂些，啟動namenode的使用者就為超級使用者。對於誰是超級使用者沒有固定的定義，當namenode啟動後，該程序的標示決定了誰是超級使用者。hdfs的超級使用者不必是namenode主機的超級使用者，也需用所有的集群使用相同的超級使用者，出於實驗目的在個人工作站上執行hdfs的人自然而然的稱為超級使用者而不需要任何配置。另外引數dfs.permissions.superusergroup設定了超級使用者，該組中的所有使用者也為超級使用者。超級使用者在hdfs中可以執行任何操作而針對超級使用者的許可權檢查永遠不會失敗。
hdfs也提供了對posix acl（訪問控制列表）支援來為特定的使用者或者使用者組提供更加細粒度的檔案許可權。acl是不同於使用者和組的自然組織層次的有用的許可權控制方式，acl可以為特定的使用者和組設定不同的許可權，而不僅僅是檔案的擁有者和檔案所屬的組。預設情況下，hdfs禁用acl，因此namenode禁止acl的建立，為了啟用acl，需要在hdfs-site.xml中將引數dfs.namenode.acls.enabled設定為true。
訪問控制列表由一組acl項組成，每個acl項命名了特定的使用者或組，並為其授予或拒絕讀，寫和執行的許可權，例如：
user::rw-user:bruce:rwx #effective:r--group::r-x #effective:r--group:sales:rwx #effective:r--mask::r--other::r--
每個acl項由型別，可選的名稱和許可權字串組成，它們之間使用冒號（:）。在上面的例子中檔案的擁有者具有讀寫許可權，檔案所屬的組具有讀和執行的許可權，其他使用者具有讀許可權，這些設定與將檔案設定為654等價（6表示擁有者的讀寫許可權，5表示組的讀和執行許可權，4表示其他使用者的讀許可權）。除此之外，還有兩個擴充套件的acl項，分別為使用者bruce和組sales，並都授予了讀寫和執行的許可權。mask項是乙個特殊的項，用於過濾授予所有命名使用者，命名組及未命名組的許可權，即過濾除檔案擁有者和其他使用者(other)之外的任何acl項。在該例子中，mask值有讀許可權，則bruce使用者、sales組和檔案所屬的組只具有讀許可權。每個acl必須有mask項，如果使用者在設定acl時沒有使用mask項，乙個mask項被自動加入到acl中，該mask項是通過計算所有被mask過濾項的許可權與（&運算）得出的。對擁有acl的檔案執行chmod實際改變的是mask項的許可權，因為mask項扮演的是過濾器的角色，這將有效地約束所有擴充套件項的許可權，而不是僅改變組的許可權而可能漏掉其它擴充套件項的許可權。
訪問控制列表和預設訪問控制列表存在著不同，前者定義了在執行許可權檢查實施的規則，後者定義了新檔案或者子目錄建立時自動接收的acl項，例如：
user::rwxgroup::r-x
other::r-x
default:user::rwx
default:user:bruce:rwx #effective:r-x
default:group::r-x
default:group:sales:rwx #effective:r-x
default:mask::r-x
default:other::r-x
只有目錄可能擁有預設訪問控制列表，當建立新檔案或者子目錄時，自動拷貝父輩的預設訪問控制列表到自己的訪問控制列表中，新的子目錄也拷貝父輩預設的訪問控制列表到自己的預設訪問控制列表中。這樣，當建立子目錄時預設acl將沿著檔案系統樹被任意深層次地拷貝。在新的子acl中，準確的許可權由模式引數過濾。預設的umask為022，通常新目錄許可權為755，新檔案許可權為644。模式引數為未命名使用者（檔案的擁有者），mask及其他使用者過濾拷貝的許可權值。在上面的例子中，建立許可權為755的子目錄時，模式對最終結果沒有影響，但是如果建立許可權為644的檔案時，模式過濾器導致新檔案的acl中檔案擁有者的許可權為讀寫，mask的許可權為讀以及其他使用者許可權為讀。mask的許可權意味著使用者bruce和組sales只有讀許可權。拷貝acl發生在檔案或子目錄的建立時，後面如果修改父輩的預設acl將不再影響已存在子類的acl。
預設acl必須包含所有最小要求的acl項，包括檔案擁有者項，檔案所屬的組項和其它使用者項。如果使用者沒有在預設acl中配置上述三項中的任何乙個，那麼該項將通過從訪問acl拷貝對應的許可權來自動插入，或者如果沒有訪問acl則自動插入許可權位。預設acl也必須擁有mask，如果mask沒有被指定，通過計算所有被mask過濾項的許可權與（&運算）自動插入mask。當乙個檔案擁有acl時，許可權檢查的演算法變為：
如果使用者名稱匹配檔案的擁有者，則測試擁有者許可權
上文的acl細粒度控制其實我也沒看很懂,不過這裡要做的多租戶隔離暫時只需要粗粒度的許可權控制即可,所以複習一下unix的posix系統許可權模型就好
預設許可權控制配置在hadoop的core-site.xml中,"fs.permissions.umask-mode"值預設為022,umask是表示反碼的意思，022是代表你在建檔案時候，系統自動用777去跟022相減得到755，你的檔案就是755的許可權，顯示出來就是wrxw-xw-x，檔案所有者有讀、寫、執行；組成員有讀、執行，其他人員有讀、執行許可權。linux中的umask引數是八進位制，而hadoop中類似作用的引數採用的是十進位制，這樣想要寫入的檔案許可權為rwxr-x---（750）,linux中umask需設為027，對應的十進位制為2*8+7=23，所以將dfs.umask引數設為023，即可達到目的。(我看網上有些人說用八進位制配置並不能生效,試一下轉十進位制)
備註:為特定的使用者和組提供細緻粒度的許可權管理, 而不只是owner,group。該功能預設關閉, 需要如下設定開啟，具體配置實在hdfs-site.xml中：
dfs.permissions.enabledtrue
dfs.namenode.acls.enabled
true
新建hadoop使用者組下的使用者後執行hadoop命令即可以擁有使用者特有的目錄,與linux使用者系統一樣.
由於專案有更高階的要求,所以這份資料先了解到這裡, 準備開啟kerberos來啟動hdfs多租戶功能,下篇文章再見
eclipse新增hadoop外掛程式
重啟eclipse 關閉hdfs伺服器的防火牆，修改相應配置檔案使之能夠通過ip加埠訪問 在window preferences hadoop map reduce下邊，選擇剛剛解壓的hadoop目錄，提交並關閉 window show view map reduce locations，建立新的h...
Hadoop集群中新增硬碟
hadoop工作節點擴充套件硬碟空間 接到老闆任務，hadoop集群中硬碟空間不夠用，要求加一台機器到hadoop集群，並且每台機器在原有基礎上加一塊2t硬碟，老闆給力啊，哈哈。這些我把完成這項任務的步驟和我遇到的問題和解決方法總結一下，分享給大家。1.首先，介紹一下用到的基本命令和配置，如果本文的...
hadoop新增節點配置步驟
新加datanode的安裝步驟 1 ssh無密碼配置和上面詳細步驟一樣，在新datanode上的 root 上建乙個 ssh的目錄，把namenode的authorized keys複製到新datanode的 ssh目錄上。在namenode上ssh驗證一下是否需要密碼。2 修改機器名，和上面詳細步...