HDFS許可權指南

概述

Hadoop分散式文件系統實現了一個和POSIX系統類似的文件和目錄的許可權模型。每個文件和目錄有一個所有者（owner）和一個組（group）。文件或目錄對其所有者、同組的其他用戶以及所有其他用戶分別有著不同的許可權。對文件而言，當讀取這個文件時需要有r許可權，當寫入或者追加到文件時需要有w許可權。對目錄而言，當列出目錄內容時需要具有r許可權，當新建或刪除子文件或子目錄時需要有w許可權，當訪問目錄的子節點時需要有x許可權。

不同於POSIX模型，由於沒有可執行文件的概念，所以HDFS許可權模型中的文件沒有setuid或setgid位。對於目錄而言，作為簡化，也沒有setuid或setgid位。可以在目錄上設置stickybit，防止超級用戶、目錄所有者或文件所有者以外的任何人刪除或移動目錄中的文件。對一個文件設置sticky bit是沒有任何作用的。總的來說，文件或目錄的許可權就是它的模式（mode）。HDFS採用了Unix表示和顯示模式的習慣，包括使用八進位數來表示許可權。當新建一個文件或目錄，它的所有者即客戶進程的用戶，它的所屬組是父目錄的組（BSD的規定）。

HDFS還為POSIX ACLs (Access Control Lists)提供了可選支持，以便為特定的命名用戶或命名組使用更細粒度的規則來增強文件許可權。本文檔稍後將更詳細地討論ACLs。

每個訪問HDFS的客戶端進程的標識分為兩個部分，分別是用戶名和組名列表。每次客戶端進程訪問一個文件或目錄foo，HDFS都要對其進行許可權檢查，

①　如果用戶即foo的所有者，則檢查所有者的訪問許可權；

②　如果foo關聯的組在組名列表中出現，則檢查組用戶的訪問許可權；

③　否則檢查foo其他用戶的訪問許可權。

如果許可權檢查失敗，則客戶端的操作會失敗。

用戶身份

1)simple

在此操作模式中，客戶端進程的標識由主機操作系統確定。在類似Unix的系統上，用戶名相當於「whoami」。

2)kerberos

無論操作模式如何，用戶標識機制對於HDFS本身都是外部的。HDFS中沒有提供用於創建用戶身份、建立組或處理用戶證書（credentials）的功能。

Group Mapping

根據上面的描述，當一個用戶名被確定後，組列表將由組映射服務確定，該服務是由hadoop.security.group.mapping來配置的。更多細節請查看Hadoop Groups Mapping。

許可權檢查

每個HDFS操作都要求用戶具有通過文件所有權、組成員資格或其他許可權授予的特定許可權(讀取、寫入和EXECUTE的某種組合)。操作可以在路徑的多個組件(而不僅僅是最終組件)上執行許可權檢查。此外，某些操作依賴於對路徑所有者的檢查。

所有操作都需要遍歷訪問。遍歷訪問要求對路徑的所有現有組件(最終路徑組件除外)具有EXECUTE許可權。例如，對於訪問/ foo / bar / baz的任何操作，調用方必須對/，/ foo和/ foo / bar具有EXECUTE許可權。

下表描述了HDFS對路徑的每個組件執行的許可權檢查。

①　Ownership:是否需要檢查調用者是否是目錄的所有者。通常，更改所有權或者元數據的許可權操作要求調用者是當前目錄的所有者。

②　Parent:請求路徑的父目錄。例如，對目錄/foo/bar/baz來說父目錄是/foo/bar。

③　Ancestor:請求路徑的上個現有組件。例如，對於路徑/ foo / bar / baz，如果存在/ foo / bar，則祖先路徑為/ foo / bar。如果/ foo存在，但/ foo / bar不存在，則祖先路徑為/ foo。

④　Final:請求路徑的最終組件。例如，目錄/foo/bar/baz最終路徑組件是/foo/bar/baz。

⑤　Sub-tree:對於作為目錄的路徑，遞歸地指定目錄本身及其所有子目錄。例如，對於具有兩個名為buz和boo的子目錄的路徑/ foo / bar / baz，子樹是/ foo / bar / baz、/ foo / bar / baz / buz和/ foo / bar / baz / boo。

1)僅當調用使用overwrite選項並且路徑上已經存在文件時，才需要在create時對最終路徑組件進行WRITE訪問。

2)如果設置了sticky bit，則檢查父目錄上的WRITE許可權的任何操作也將檢查所有權。

3)調用setOwner以更改文件的擁有用戶需要HDFS超級用戶訪問許可權。更改組不需要HDFS超級用戶訪問許可權，但調用者必須是文件的所有者和指定組的成員。

理解系統的實現

每次文件或目錄操作都需要傳遞完整的路徑名給NameNode，每一個操作都會對此路徑做許可權檢查。客戶框架會隱式地將用戶身份和與NameNode的連接關聯起來，從而減少改變現有客戶端API的需求。經常會有這種情況，當對一個文件的某一操作成功後，之後同樣的操作卻會失敗，這是因為文件或路徑上的某些目錄已經不復存在了。比如，客戶端首先開始讀一個文件，它向NameNode發出一個請求以獲取文件第一個數據塊的位置。但接下去的獲取其他數據塊的第二個請求可能會失敗。另一方面，刪除一個文件並不會撤銷客戶端已經獲得的對文件數據塊的訪問許可權。而許可權管理能使得客戶端對一個文件的訪問許可在兩次請求之間被收回。重複一下，許可權的改變並不會撤銷當前客戶端對文件數據塊的訪問許可。

File System API的改變

如果許可權檢查失敗，所有使用path參數的方法都將引發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, …)方法（沒有指定許可權參數）時，新文件的模式是0666 ?&?^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…

文件的所有者的只能被超級用戶更改。

④　lsfile…

⑤　lsrfile…

輸出格式做了調整以顯示所有者、組和模式。

超級用戶

超級用戶即運行NameNode進程的用戶。寬泛的講，如果你啟動了NameNode，你就是超級用戶。超級用戶能幹任何事情，因為超級用戶能夠通過所有的許可權檢查。沒有永久記號保留誰過去是超級用戶；當NameNode開始運行時，進程自動判斷誰現在是超級用戶。HDFS的超級用戶不一定非得是NameNode主機上的超級用戶，也不需要所有的集群的超級用戶都是一個。同樣的，在個人工作站上運行HDFS的實驗者，不需任何配置就已方便的成為了他的部署實例的超級用戶。

另外，管理員可以用配置參數指定一組特定的用戶，如果做了設定，這個組的成員也會是超級用戶。

Web伺服器

Web伺服器的身份是一個可配置參數。NameNode並沒有真實用戶的概念，但是Web伺服器表現地就像它具有管理員選定的用戶的身份（用戶名和組）一樣。除非這個選定的身份是超級用戶，否則會有名字空間中的一部分對Web伺服器來說不可見。

ACLs (Access Control Lists)

除了傳統的POSIX許可權模型之外，HDFS還支持POSIXACLs (Access Control Lists)。ACLs可用於實現不同於用戶和組的自然組織層次結構的許可權要求。ACL提供了一種方法，可以為特定的命名用戶或命名組設置不同的許可權，而不僅僅是文件的所有者和文件的組。

一個ACL由一組ACLentries組成。每個ACLentry為特定用戶或組命名，並授予或拒絕該特定用戶或組的讀取、寫入和執行許可權。例如:

user::rw-

user:bruce:rwx #effective:r--

group::r-x #effective:r--

group:sales:rwx #effective:r--

mask::r--

other::r--

ACLentries由類型、可選名稱和許可權字元串組成。為便於顯示，" : "用作每個欄位之間的分隔符。在此ACL示例中，文件所有者具有讀-寫訪問許可權，文件組具有讀-執行訪問許可權，其他人具有讀訪問許可權。到目前為止，這相當於將文件的許可權位設置為654。

此外，命名用戶bruce和命名組sales還有兩個擴展ACLentries，這兩個條entries都被授予了完全訪問許可權。mask是一個特殊的ACLentry，用於篩選授予所有命名用戶entries和命名組entries以及未命名組entry的許可權。在本示例中，mask僅具有讀取許可權，我們可以看到已相應地篩選了多個ACLentries的有效許可權。

每個ACL必須有一個mask。如果用戶設置ACL的時候沒有指定mask，那麼通過計算所有entries的許可權聯合填充到mask來自動生成一個mask並插入。

在一個具有ACL的文件上運行chmod命令，將會改變mask的許可權。由於mask用作篩選器，因此這有效地限制了所有擴展ACLentries的許可權，而不是（僅更改組entry和可能丟失其他擴展ACLentries）。

該模型還區分了「access ACL」和「defaultACL」，前者定義了許可權檢查期間要強制執行的規則，後者定義了新子文件或子目錄在創建期間自動接收的ACLentries。例如:

user::rwx

group::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來作為自己的access ACL。一個新的子目錄也將它複製到自己的默認ACL。這樣，在創建新的子目錄時，默認ACL將通過文件系統樹的層次向下複製。

新子級別的access ACL的確切許可權將通過mode參數進行篩選。考慮到默認的umask 022,對於新目錄來說，通常是755，新文件通常是644。mode參數篩選未命名用戶（文件所有者）的複製許可權值，mask和其他的複製許可權值。使用此特定示例ACL，並為該模式創建一個具有755的新子目錄，此模式篩選對最終結果沒有影響。但是，如果我們考慮為模式創建644的文件，則模式篩選將導致新文件的ACL接收未命名用戶(文件所有者)的讀寫、mask的讀取和其他用戶的讀取。此mask還意味著命名用戶bruce和命名組sales的有效許可權是只讀。

請注意，拷貝發生在創建新文件或子目錄時。對父級默認ACL的後續更改不會更改現有子級。

默認ACL必須具有所有必需的最小ACLentries，包括未命名用戶(文件所有者)、未命名組(文件組)和其他entries。如果用戶在設置默認ACL時不提供這些entries之一，則通過從訪問ACL複製相應的許可權自動插入這些entries；如果沒有訪問ACL，則複製許可權位。默認ACL還必須具有mask。如上所述，如果未指定mask，則通過計算掩碼將過濾的所有entries上的許可權聯合來自動插入mask。

當考慮具有ACL的文件時，許可權檢查演算法將更改為：

①　如果用戶名與文件的所有者匹配，則測試所有者許可權；

②　如果用戶名與其中一個命名用戶entries中的名稱匹配，則測試這些許可權，並通過mask許可權進行篩選；

③　如果文件組與組列表中的任何成員匹配，並且由mask篩選的這些許可權授予訪問許可權，則使用這些許可權；

④　如果有一個命名組entry與組列表的成員匹配，並且由mask篩選的這些許可權授予訪問許可權，則使用這些許可權；

⑤　如果文件組或任何命名組entry與組列表中的成員匹配，但這些許可權中的任何一個都沒有授予訪問許可權，則拒絕訪問；

⑥　否則測試文件的其他許可權。

最佳做法是依賴傳統的許可權位來實現大多數許可權要求，並定義較少數量的ACLs以使用一些例外規則來擴充許可權位。與只有許可權位的文件相比，具有ACL的文件在NameNode的內存中會增加額外開銷。

ACLs File System API

新方法：

①　public void modifyAclEntries(Path path, List aclSpec) throws IOException;

②　public void removeAclEntries(Path path, List aclSpec) throws IOException;

③　public void public void removeDefaultAcl(Path path) throws IOException;

④　public void removeAcl(Path path) throws IOException;

⑤　public void setAcl(Path path, List aclSpec) throws IOException;

⑥　public AclStatus getAclStatus(Path path) throws IOException;

ACLs Shell Commands

①　hdfs dfs -getfacl [-R]

顯示文件和目錄的Access Control Lists (ACLs).如果目錄有一個默認的ACL，則getfacl也會顯示默認的ACL。

②　hdfs dfs -setfacl [-R] [-b |-k -m |-x

] |[--set

]

設置文件和目錄的Access Control Lists (ACLs)。

③　hdfs dfs -ls

ls的輸出將在具有ACL的任何文件或目錄的許可權字元串中附加一個「+」字元。

查看File System Shell文檔來獲得這些命令的詳細信息。

配置參數

如果是true，則打開前文所述的許可權系統。如果是false，許可權檢查就是關閉的，但是其他的行為沒有改變。這個配置參數的改變並不改變文件或目錄的模式、所有者和組等信息。不管許可權模式是開還是關，chmod，chgrp，chown和setfacl總是會檢查許可權。這些命令只有在許可權檢查背景下才有用，所以不會有兼容性問題。這樣，這就能讓管理員在打開常規的許可權檢查之前可以可靠地設置文件的所有者和許可權。

Web伺服器使用的用戶名。如果將這個參數設置為超級用戶的名稱，則所有Web客戶端就可以看到所有的信息。如果將這個參數設置為一個不使用的用戶，則Web客戶端就只能訪問到「other」許可權可訪問的資源了。額外的組可以加在後面，形成一個用逗號分隔的列表。

超級用戶的組名。

在創建文件和目錄時使用的umask。在配置文件中，可以使用十進位數18。

指定為ACL的集群的管理員。這控制在HDFS中，誰可以訪問默認servlet等。

設置為true以啟用對ACLs (Access Control Lists)的支持。默認情況下，ACLs處于禁用狀態。禁用ACL後，NameNode將拒絕所有設置ACL的嘗試。

------------全文完--------------------

備註：

模式：mode

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！

本站內容充實豐富，博大精深，小編精選每日熱門資訊，隨時更新，點擊「搶先收到最新資訊」瀏覽吧！

請您繼續閱讀更多來自 程序猿碼碼 的精彩文章:

TAG:程序猿碼碼 |