題 文件權限如何應用於符號鏈接?


假設你有這種結構:

+ directory
-- file1
-- file2
-- file3 -> /tmp/file3

file3 是另一個鏈接 file3 系統上的其他地方。

現在讓我們說我 chmod 777 目錄及其中的所有內容。我的 file3 在 /tmp 收到這些權限?而且,讓我們說我們有相同的情況,但逆轉。

/tmp/file3 -> /directory/file3

如果我對鏈接的文件應用權限,這對鏈接有何影響?


81
2018-06-27 20:42


起源


權限僅影響文件,而不影響符號鏈接。 - baraboom


答案:


這取決於你如何打電話 chmod 以及您正在運行的平台。

例如,在Linux系統上, man chmod 這樣說:

chmod  永遠不會改變符號鏈接的權限;該 chmod   系統調用無法更改其權限。這不是問題   因為永遠不會使用符號鏈接的權限。然而,   對於命令行中列出的每個符號鏈接, chmod 改變了   指向文件的權限。相反, chmod 忽略   遞歸目錄遍歷期間遇到的符號鏈接。

但是,在Mac上,chmod可用於使用諸如此類的選項來修改符號鏈接的權限(來自 man chmod):

-h如果文件是符號鏈接,請更改鏈接的模式   本身而不是鏈接指向的文件。

為了舉例,我們假設你在Linux機器上用於本答案的其餘部分。

如果在第一種情況下你運行 chmod -R 777 directory 要遞歸更改權限,鏈接目標不會受到影響,但如果你這樣做 chmod 777 directory/*, 它會。

如果直接更改鏈接目標的權限,那麼這些權限將繼續執行(因為作為手冊頁和 baraboom 比如說,實際的鏈接權限不用於任何東西)。


測試日誌的插圖:

$ mkdir dir && touch dir/file{1,2} /tmp/file3 && ln -s {/tmp,dir}/file3
$ ls -l dir/* /tmp/file3
-rw-r--r-- 1 user group  0 2011-06-27 22:02 /tmp/file3
-rw-r--r-- 1 user group  0 2011-06-27 22:02 dir/file1
-rw-r--r-- 1 user group  0 2011-06-27 22:02 dir/file2
lrwxrwxrwx 1 user group 10 2011-06-27 22:02 dir/file3 -> /tmp/file3

$ chmod -R 777 dir && ls -l dir/* /tmp/file3
-rw-r--r-- 1 user group  0 2011-06-27 22:02 /tmp/file3
-rwxrwxrwx 1 user group  0 2011-06-27 22:02 dir/file1
-rwxrwxrwx 1 user group  0 2011-06-27 22:02 dir/file2
lrwxrwxrwx 1 user group 10 2011-06-27 22:02 dir/file3 -> /tmp/file3

$ chmod 700 dir/* && ls -l dir/* /tmp/file3
-rwx------ 1 user group  0 2011-06-27 22:02 /tmp/file3
-rwx------ 1 user group  0 2011-06-27 22:02 dir/file1
-rwx------ 1 user group  0 2011-06-27 22:02 dir/file2
lrwxrwxrwx 1 user group 10 2011-06-27 22:02 dir/file3 -> /tmp/file3

81
2018-06-27 21:23



這對我來說也是一個驚喜。下一個問題:誰在符號鏈接上執行權限 意思? - Edward Falk
@EdwardFalk符號鏈接權限不是非限制性的,因為所有內容都需要能夠遍歷它以從鏈接文件中獲取權限。 - Walf


baraboom和peth的答案都是正確的:符號鏈接本身的權限位是無關緊要的(macOS除外;見下文),以及更改符號鏈接的權限 - 由 chmod 命令行工具或由 chmod() 系統調用 - 將簡單地表現為對符號鏈接的目標執行。

報價 symlink()系統調用的SUSv4 / POSIX.1-2008描述

未指定所創建的符號鏈接的文件模式位的值。 POSIX.1-2008指定的所有接口的行為應該始終可以讀取符號鏈接的內容,除了在文件模式位中返回的值。 ST_MODE 的領域 統計 結構未指定。

在這裡,“未指定”為每個實現留下了解釋空間。具體細節:

  • 在Linux上(使用ext4fs測試), stat() 回報 st_mode=0777,無論創建符號鏈接時umask是什麼; ls -l 因此總是顯示 lrwxrwxrwx 用於符號鏈接。
  • 在macOS(HFS)和FreeBSD(UFS和ZFS)上,符號鏈接確實有自己的權限: chmod -h 上面提到的命令可以更改此鏈接權限(內部使用非POSIX) lchown()系統調用實現此),和 stat() 系統調用返回此值 st_mode

按照POSIX的規定,始終可以遵循Linux和FreeBSD上的符號鏈接。特別是在FreeBSD上,這意味著符號鏈接的文件模式對訪問控製完全沒有影響。

另一方面,macOS略微破壞了POSIX。雖然無論其讀取權限如何,都可以遵循符號鏈接, readlink() 失敗了 EACCES (權限被拒絕)如果用戶沒有讀取權限:

$ sudo ln -shf target symlink
$ sudo chmod -h 444 symlink
$ ls -l symlink
lr--r--r--  1 root  staff  1 Mar 14 13:05 symlink -> target
$ sudo chmod -h 000 symlink
$ ls -l symlink

ls: symlink: Permission denied
l---------  1 root  staff  1 Mar 14 13:05 symlink
$ echo kthxbye > target
$ cat symlink
kthxbye

(注意 -> target 第二個輸出中缺少部分 ls -l 命令,那 cat symlink 仍然成功並打印了內容 target 文件,即使用戶沒有讀取權限 symlink。)

NetBSD顯然提供了一個名為的特殊掛載選項 symperm 如果設置,則會導致符號鏈接讀取/執行權限以進行控制 readlink() 和鏈接遍歷。


2
2018-03-14 20:32





  1. 刪除鏈接文件(確保它不被任何進程使用)
  2. 設置umask以使777-umask =所需的文件權限
  3. 重新創建鏈接文件

-2
2017-10-02 05:48



這是如何回答這個問題的? - jww