網管技術
NFS 的檔案存取權限
不知道你有沒有想過這個問題，在圖 13.1-1 的環境下，假如我在 NFS client 1 上面以 dmtsai 這個使用者身份想要去存取 /home/data/sharefile/ 這個來自 NFS server 所提供的檔案系統時， 請問 NFS server 所提供的檔案系統會讓我以什麼身份去存取？是 dmtsai 還是？
為什麼會這麼問呢？這是因為 NFS 本身的服務並沒有進行身份登入的識別， 所以說，當你在用戶端以 dmtsai 的身份想要存取伺服器端的檔案系統時， 伺服器端會以用戶端的使用者 UID 與 GID 等身份來嘗試讀取伺服器端的檔案系統。這時有個有趣的問題就產生啦！ 那就是如果用戶端與伺服器端的使用者身份並不一致怎麼辦？ 我們以底下這個圖示來說明一下好了：
圖 13.1-3、NFS 的伺服器端與用戶端的使用者身份確認機制
當我以 dmtsai 這個一般身份使用者要去存取來自伺服器端的檔案時，你要先注意到的是： 檔案系統的 inode 所記錄的屬性為 UID, GID 而非帳號與群組名。 那一般 Linux 主機會主動的以自己的 /etc/passwd, /etc/group 來查詢對應的使用者、群組名稱。 所以當 dmtsai 進入到該目錄後，會參照 NFS client 1 的使用者與群組名稱。 但是由於該目錄的檔案主要來自 NFS server ，所以可能就會發現幾個情況：
- NFS server/NFS client 剛好有相同的帳號與群組
則此時使用者可以直接以 dmtsai 的身份進行伺服器所提供的檔案系統之存取。
- NFS server 的 501 這個 UID 帳號對應為 vbird
若 NFS 伺服器上的 /etc/passwd 裡面 UID 501 的使用者名稱為 vbird 時， 則用戶端的 dmtsai 可以存取伺服器端的 vbird 這個使用者的檔案喔！只因為兩者具有相同的 UID 而已。這就造成很大的問題了！因為沒有人可以保證用戶端的 UID 所對應的帳號會與伺服器端相同， 那伺服器所提供的資料不就可能會被錯誤的使用者亂改？
- NFS server 並沒有 501 這個 UID
另一個極端的情況是，在伺服器端並沒有 501 這個 UID 的存在，則此時 dmtsai 的身份在該目錄下會被壓縮成匿名者， 一般 NFS 的匿名者會以 UID 為 65534 為其使用者，早期的 Linux distributions 這個 65534 的帳號名稱通常是 nobody ，我們的 CentOS 則取名為 nfsnobody 。但有時也會有特殊的情況，例如在伺服器端分享 /tmp 的情況下， dmtsain 的身份還是會保持 501 但建立的各項資料在伺服器端來看，就會屬於無擁有者的資料。
- 如果使用者身份是 root 時
有個比較特殊的使用者，那就是每個 Linux 主機都有的 UID 為 0 的 root 。 想一想，如果用戶端可以用 root 的身份去存取伺服器端的檔案系統時，那伺服器端的資料哪有什麼保護性？ 所以在預設的情況下， root 的身份會被主動的壓縮成為匿名者。
總之，用戶端使用者能做的事情是與 UID 及其 GID 有關的，那當用戶端與伺服器端的 UID 及帳號的對應不一致時， 可能就會造成檔案系統使用上的困擾，這個就是 NFS 檔案系統在使用上面的一個很重要的地方！ 而在瞭解使用者帳號與 UID 及檔案系統的關係之後，要實際在用戶端以 NFS 取用伺服器端的檔案系統時， 你還得需要具有：
- NFS 伺服器有開放可寫入的權限 (與 /etc/exports 設定有關)；
- 實際的檔案權限具有可寫入 (w) 的權限。
當你滿足了 (1)使用者帳號，亦即 UID 的相關身份； (2)NFS 伺服器允許有寫入的權限； (3)檔案系統確實具有 w 的權限時，你才具有該檔案的可寫入權限喔！ 尤其是身份 (UID) 確認的環節部分，最容易搞錯啦！也因為如此， 所以 NFS 通常需要與 NIS (十四章) 這一個可以確認用戶端與伺服器端身份一致的服務搭配使用，以避免身份的錯亂啊！ ^_^