如何完全控制 umask/PAM/權限？

// 2 月 8 日更新 - 未決問題簡介：

• 如何以不同於文件的方式屏蔽目錄？
• 如何在 Nautilus 複製/粘貼上取消遮罩？
• 如何為 SSHFS 設置 umask？

我們的情況

我們公司的幾個人登錄到伺服器並上傳文件。他們都需要能夠上傳和覆蓋相同的文件。他們有不同的使用者名，但都屬於同一個組。但是，這是一個網際網路伺服器，因此“其他”使用者應該（通常）只有隻讀訪問權限。所以我想要的是這些標準權限：

文件：664

目錄：771

我的目標是所有使用者都不需要擔心權限問題。伺服器的配置方式應使這些權限適用於所有文件和目錄，無論是新創建的、複製的還是覆蓋的。只有當我們需要一些特殊權限時，我們才會手動更改它。

我們通過在 Nautilus 中通過 SFTP-ing 將文件上傳到伺服器，通過使用 sshfs 掛載伺服器並在 Nautilus 中訪問它，就好像它是本地文件夾一樣，並在命令行中通過 SCP-ing。這基本上涵蓋了我們的情況和我們的目標。

現在，我已經閱讀了很多關於漂亮的 umask 功能的內容。據我了解，umask（與 PAM 一起）應該允許我做我想做的事：為新文件和目錄設置標準權限。然而，經過許多小時的閱讀和反複試驗，我仍然無法讓它發揮作用。我得到了很多意想不到的結果。我真的很想牢牢掌握 umask 並且有很多問題沒有得到解答。我將在下面發布這些問題，連同我的發現和對導致這些問題的試驗的解釋。鑑於許多事情似乎出錯了，我認為我做錯了幾件事。因此，有很多問題。

注意：我使用的是 Ubuntu 9.10，因此無法更改 sshd_config來設置 SFTP 伺服器的 umask。已安裝 SSH OpenSSH_5.1p1 Debian-6ubuntu2 < 需要 OpenSSH 5.4p1。所以這裡有問題。

1. 我需要重新啟動 PAM 更改才能生效嗎？

讓我們從這個開始。涉及的文件太多，我無法弄清楚什麼會影響事情，什麼不會影響事情，也是因為我不知道是否必須重新啟動整個系統才能使 PAM 更改生效。我是在沒有看到預期結果後才這樣做的，但這真的有必要嗎？或者我可以從伺服器註銷然後重新登錄，新的 PAM 策略應該有效嗎？或者是否有一些“PAM”程序可以重新載入？

2. 是否有一個文件可以更改影響所有會話的所有使用者？

所以我最終改變了很多文件，因為我讀了很多不同的東西。我最終在以下文件中設置了 umask：

~/.profile -> umask=0002
~/.bashrc -> umask=0002
/etc/profile -> umask=0002
/etc/pam.d/common-session -> umask=0002
/etc/pam.d/sshd -> umask=0002
/etc/pam.d/login -> umask=0002

我希望此更改適用於所有使用者，因此最好進行某種系統範圍的更改。可以實現嗎？

3. 畢竟，這個 UMASK 東西有用嗎？

因此，在每個可能的地方將 umask 更改為 0002 之後，我執行測試。

————SCP———–

測試 1：

scp testfile (which has 777 permissions for testing purposes) server:/home/
testfile                                      100%    4     0.0KB/s   00:00   

讓我們檢查權限：

user@server:/home$ ls -l
total 4
-rwx--x--x 1 user uploaders 4 2011-02-05 17:59 testfile (711)

更新：僅通過在 pam.d/common-sessions 中設置 umask 來修復（見評論）

———SSH————

測試 2：

ssh server
user@server:/home$ touch anotherfile
user@server:/home$ ls -l
total 4
-rw-rw-r-- 1 user uploaders 0 2011-02-05 18:03 anotherfile (664)

——–SFTP————

鸚鵡螺：sftp://server/home/

將新文件從客戶端複製並粘貼到伺服器（客戶端上為 777）

測試 3：

user@server:/home$ ls -l
total 4
-rwxrwxrwx 1 user uploaders 3 2011-02-05 18:05 newfile (777)

通過 Nautilus 創建一個新文件。檢查終端中的文件權限：

測試 4：

user@server:/home$ ls -l
total 4
-rw------- 1 user uploaders    0 2011-02-05 18:06 newfile (600)

我的意思是……這裡剛剛發生了什麼？！我們應該每次都得到 644。相反，我得到 711、777、600，然後是 644。只有通過 SSH 創建一個新的空白文件時才能實現 644，這是最不可能的情況。

所以我問，umask/pam 到底有用嗎？

更新：通過僅在 pam.d/common-sessions 中設置 umask 來修復測試 4（見評論）

4. 那麼 UMASK SSHFS 是什麼意思？

有時我們使用 sshfs 在本地安裝伺服器。很有用。但同樣，我們有權限問題。

以下是我們的掛載方式：

sshfs -o idmap=user -o umask=0113 user@server:/home/ /mnt

注意：我們使用 umask = 113 因為顯然 sshfs 從 777 而不是 666 開始，所以使用 113 我們得到 664，這是所需的文件權限。

但是現在發生的情況是，我們看到所有文件和目錄就好像它們是 664。我們在 Nautilus 中瀏覽到 /mnt，然後：

• 右鍵 -> 新建文件（newfile）— TEST 5
• 右鍵->新建文件夾（newfolder）— TEST 6
• 從我們的本地客戶端複製並粘貼一個 777 文件 — TEST 7

所以讓我們在命令行上檢查一下：

user@client:/mnt$ ls -l
total 8
-rw-rw-r-- 1 user 1007    3 Feb  5 18:05 copyfile (664)
-rw-rw-r-- 1 user 1007    0 Feb  5 18:15 newfile (664)
drw-rw-r-- 1 user 1007 4096 Feb  5 18:15 newfolder (664)

但是，嘿，讓我們檢查一下伺服器端的同一個文件夾：

user@server:/home$ ls -l
total 8
-rwxrwxrwx 1 user uploaders    3 2011-02-05 18:05 copyfile (777)
-rw------- 1 user uploaders    0 2011-02-05 18:15 newfile (600)
drwx--x--x 2 user uploaders 4096 2011-02-05 18:15 newfolder (711)

什麼？！真正的文件權限與我們在 Nautilus 中看到的非常不同。那麼 sshfs 上的這個 umask 是否只是創建了一個顯示虛幻文件權限的“過濾器”？我試圖從另一個使用者打開一個文件，但同一組具有真正的 600 權限但 644 的“假”權限，我仍然無法閱讀這個，那麼這個過濾器有什麼用？

5. UMASK 是關於文件的。但是目錄呢？

從我的測試中，我可以看到正在應用的 umask 也會以某種方式影響目錄權限。但是，我希望我的文件是 664 (002)，我的目錄是 771 (006)。那麼目錄可以有不同的umask嗎？

6. 也許 UMASK/PAM 真的很酷，但 UBUNTU 只是有問題？

一方面，我讀過那些在 PAM/UMASK 和 Ubuntu 上取得成功的人的話題。另一方面，我在 Ubuntu 上發現了許多關於 umask/PAM/fuse 的新舊錯誤：

• https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/241198
• https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/239792
• https://bugs.launchpad.net/ubuntu/+source/pam/+bug/253096
• https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/549172
• http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=314796

所以我不知道該相信什麼了。我應該放棄嗎？ACL 能解決我所有的問題嗎？還是我在使用 Ubuntu 時再次遇到問題？

使用 tar 進行備份時要注意一點。Red Hat /Centos 發行版在 tar 程序中支持 acls，但 Ubuntu 在備份時不支持 acls。這意味著當您創建備份時，所有 acl 都將失去。

如果這也能解決我的問題，我非常願意升級到 Ubuntu 10.04，但首先我想了解發生了什麼。

很多事情都可能發生在這裡。

第一個想法：

• 是的，pam.d 更改立即生效
• /etc/pam.d/common-session是設置預設值的最佳位置umask
• 任何 pam.d umask 都會被 中的任何條目覆蓋.bashrc，

但.bashrc只會在某些情況下被讀取（互動式、非登錄 shell）

• testfile (711)很奇怪

  • 如何/home安裝，您是否使用 ACL？

  （例如做什麼ls -ld /home和getfacl /home列印？）

  • testfile在您進行複制之前已經存在，因為不會scp更改已經存在的文件的權限（除非您使用該-p標誌）

• 眾所周知，Nautilus 以不同的方式創建文件，不確定原因或規則是什麼

• umask=0113可能會導致問題

• 伺服器和客戶端是否執行相同的作業系統？

例如，如果客戶端啟用了​​ ACL，或者是 Cygwin，則行為可能會有所不同

• 強制健全權限的最佳方法是使用預設 ACL，正是因為，正如您所發現的，umask它可以被.bashrc和中的使用者覆蓋.bash_profile。

更新：

• umask=0113因為 sshfs 是錯誤的。

  1. 嘗試安裝而不指定umask
  2. 使用 . 在掛載點內創建一個新文件touch。
  3. 你應該看到它只得到例如-rw-r--r--，沒有x位
  4. 通過屏蔽x位，您可能會破壞目錄

  並且編譯器可能無法正確創建執行檔

解決方法：

如果我們想不出更好的方法，您可以使用fam或gamin觀察正在創建的新文件並修復它們的權限，或者甚至只是一個定期執行並設置所有文件權限的腳本。

引用自：https://serverfault.com/questions/231717