chown(1) POSIX 規範的解釋

Question 1

這Microsoft Interix Unix 子系統 （現已退休）因為它的 NT 核心對使用者和群組權限的處理與其他一些核心略有不同：

使用者和群組資訊儲存在安全存取資料庫。使用者和群組都儲存在同一個資料庫中，但群組和使用者名稱必須唯一；任何群組都不能擁有使用者名，反之亦然。（該資料庫取代了UNIX 中的/etc/passwd和/etc/groups檔案。）使用者和群組是使用適當的 Windows 方法建立的（使用者管理員、Active Directory 使用者和電腦或本機使用者和群組）或使用 Win32net user命令。（用於建立和刪除使用者的範例 shell 腳本包含在目錄中/usr/examples/admin。）使用者可以屬於多個群組。

這裡有一些更具體的手冊摘錄：

在 Windows 中，使用者或群組都可以擁有物件。這與 UNIX 不同，在 UNIX 中，只有使用者擁有物件。

Windows 使用安全性識別碼在內部識別所有使用者和群組（安全識別碼）。哈希演算法產生唯一的 SID 值；沒有兩個使用者或群組具有相同的 SID。

有權存取物件的使用者和群組由其 SID 標識。 Windows 可以保護的所有物件都有一個任意存取控制清單 (DACL)，它由稱為存取控制條目 (ACE) 的單獨條目組成。 ACE 包含兩個重要資訊：使用者或群組 SID，以及單一使用者或群組對物件擁有多少存取權限的描述。

CHGRP

....更改檔案的群組 ID ...呼叫 chgrp(1) 的使用者必須屬於指定的群組並且是檔案的擁有者，或具有適當的權限。

莊

...擁有者和群組操作數都是可選的；然而，必須指定一個。如果指定了群組運算元，則其前面必須帶有冒號 (:)。

所有者可以透過數字用戶 ID 或用戶名指定。如果使用者名稱也是數字使用者 ID，則操作數將用作使用者名稱。該組可以是數字組 ID 或組名稱。如果群組名稱也是數字組 ID，則操作數將用作群組名稱。

出於安全原因，檔案的所有權只能由具有適當權限的進程變更。

正如我所讀到的，這意味著如果您的使用者帳戶屬於 Windows 群組，並且該群組具有足夠的權限來修改該群組所擁有的檔案的權限，那麼就可以有效地chgrp在您的使用者帳戶的控制範圍之外存取該文件。這相當於比使用chown顯式user:group參數時的控制要少。在這種情況下，無法聲明user: 和 :group你永遠無法獲得與其他方式相同的結果。

這是一個連結詳細了解 Interix 如何與 Windows ACL 交互，重點關注這些知識如何應用於其他 Unix 變體上的 Samba 檔案系統。

這是一個連結到現在過時的Solaris 文件描述了可調參數rstchown...

指示系統呼叫的 POSIX 語意學是否chown(2)有效...

顯然，如果參數設定為值0...

....關閉 POSIX 語意可能會帶來各種安全漏洞。這也開啟了一種可能性使用者將文件的所有權更改給另一個使用者並且無法檢索該文件無需使用者或系統管理員的干預即可返回。

這樣的選項不會使 Solaris 的POSIX 一致性。僅僅因為它是一個選項，就足以使其成為一致的:

儘管符合 POSIX.1-2008 的所有實作都支援下面描述的所有功能，但可能存在可以刪除或修改的與系統相關或與檔案系統相關的設定過程 任何或所有這些功能。如果需要嚴格遵守，則不應進行此類配置。

以下符號常數應定義為 -1 以外的值。如果常數定義為零值，則應用程式應使用sysconf()、pathconf()、或fpathconf()函數或 getconf實用程式來確定當時系統上或所討論的特定路徑名存在哪些功能。

_POSIX_CHOWN_RESTRICTED

的使用chown()僅限於具有適當權限的進程，並且只能將檔案的群組 ID 變更為該進程的有效群組 ID 或其補充群組 ID 之一。

系統chown()函數 - 這是由雙方進行的記錄的系統調用chown和chgrpshell 實用程式 - 是指定失敗出於多種原因。他們之中：

EACCES 路徑前綴的某個組成部分的搜尋權限被拒絕。

ELOOP 解析路徑參數期間遇到的符號連結中存在循環。

EPERM 有效使用者 ID 與檔案擁有者不匹配，或呼叫進程沒有適當的權限和_POSIX_CHOWN_RESTRICTED表示需要這樣的特權。

然而，授予非 root 使用者權限修改權的行為從來都不是 Solaris 所獨有的。有非常優秀的- 如果有些過時 - Unix 檔案權限的覆蓋範圍這個論壇貼文作者在其中指出：

最初，Unix 允許檔案擁有者放棄檔案。文件的擁有者可以將所有者更改為其他人。非 root 使用者無法撤銷此操作... BSD[之後]chown從非 root 使用者中刪除....[部分原因]...它實現了磁碟配額，這可能會限制用戶在檔案系統中可以擁有的磁碟空間大小...頑皮的用戶可能會放棄大檔案來偷偷超過配額。

今天，很難說非 root 是否可以chown存取文件。許多 Unix 版本都允許兩個都行為...

另一個好的 - 也是最近的 -郵件清單貼文引用此並繼續：

大多數作業系統的預設設定chown僅限於 root 使用者。人們一致認為，出於安全考慮，應該保持這種狀態。如果非 root 使用者確實更改了檔案的擁有者並且任何執行位元處於開啟狀態，則必須清除SUID和位元。SGID這可能會也可能不會發生root。

我認為最後一段說得很好。

該文章還提到了CAP_CHOWN在 Linux 上控制該設施（這應該只影響POSIX_CHOWN_RESTRICTED行為）。還有一種CAP_FOWNER能力，其行為略有不同。

並作為你在2003年指出:

請注意，至少在 HPUX 上，您可以變更檔案的擁有者（root例如）即使您不是特權使用者...

....這取決於配置setprivgroup參數。

在任何情況下，非 root 使用者可以操縱檔案權限，這是可以想像的，例如理由在您的問題中引用，用戶可能chown擁有該用戶擁有的文件，以便該文件由另一個用戶擁有。如果檔案的群組所有權和chown使用者的群組不一致，則使用者將無法再修改該檔案。

在這種情況下chown 然後 chgrp將會失敗，因為用戶將不再有權更改該文件的權限，而chown user:group- 只要團體是用戶自己之中的——就會成功。

有大概許多其他利基情況可能會產生類似的結果，其中可能包括目錄黏和/或設定gid位元、檔案系統和/或特定於實現的存取控制清單。這個線程例如，很有趣。無數的排列遠遠超出了我自己微弱的掌握——這就是為什麼這個答案被維基百科。如果您正在閱讀本文，您相信它值得改進，並且您相信您知道如何 -請這樣做。

還有大量關於文件權限、樹遍歷和符號連結的各種可能影響的文檔，這些影響可能會導致遞歸-R應用程式出現類似的失敗chown：

從POSIX XRAT章節標題第三和第四域:

通常，指定檔案層次結構遍歷選項的使用者希望在單一物理層次結構上進行操作，因此可能引用層次結構以外的檔案的符號連結將被忽略。例如，chownowner file 與指定了 -R 選項的相同命令是不同的操作。在此範例中，此處描述了命令的行為chown owner file，而命令的行為chown -R所有者文件在第三和第四域中描述。

...預設邏輯行走存在安全問題。歷史上，命令chown -R用戶檔案對於超級用戶來說是安全的，因為設定值和設定gid當檔案的所有權變更時，位元會遺失。如果步行是合乎邏輯的，則更改所有權將不再安全，因為使用者可能插入了指向樹中任何檔案的符號連結。同樣，這將需要向執行層次結構遍歷的命令添加一個選項，以不間接通過符號鏈接，並且執行遞歸遍歷的歷史腳本將立即成為安全問題。雖然這對系統管理員來說主要是一個問題，但最好不要為不同類別的使用者設定不同的預設值。

…

在 4.3 BSD 中，chgrp在樹遍歷期間更改了符號連結的群組，而不是目標。 4.4 BSD 中的符號連結沒有所有者、群組、模式或其他標準 UNIX 系統檔案屬性。

以及來自 POSIXchgrp正確的頁面有 this 指向可能不完整的-R遞歸操作，或至少指向什麼用過的成為：

System V 和 BSD 版本使用不同的退出狀態代碼。一些實現使用退出狀態作為發生的錯誤數量的計數；這種做法是行不通的，因為它可能會溢出有效退出狀態值的範圍。標準開發人員選擇透過僅指定 0 和 >0 作為退出值來屏蔽這些。

Answer

這Microsoft Interix Unix 子系統 （現已退休）因為它的 NT 核心對使用者和群組權限的處理與其他一些核心略有不同：

使用者和群組資訊儲存在安全存取資料庫。使用者和群組都儲存在同一個資料庫中，但群組和使用者名稱必須唯一；任何群組都不能擁有使用者名，反之亦然。（該資料庫取代了UNIX 中的/etc/passwd和/etc/groups檔案。）使用者和群組是使用適當的 Windows 方法建立的（使用者管理員、Active Directory 使用者和電腦或本機使用者和群組）或使用 Win32net user命令。（用於建立和刪除使用者的範例 shell 腳本包含在目錄中/usr/examples/admin。）使用者可以屬於多個群組。

這裡有一些更具體的手冊摘錄：

在 Windows 中，使用者或群組都可以擁有物件。這與 UNIX 不同，在 UNIX 中，只有使用者擁有物件。

Windows 使用安全性識別碼在內部識別所有使用者和群組（安全識別碼）。哈希演算法產生唯一的 SID 值；沒有兩個使用者或群組具有相同的 SID。

有權存取物件的使用者和群組由其 SID 標識。 Windows 可以保護的所有物件都有一個任意存取控制清單 (DACL)，它由稱為存取控制條目 (ACE) 的單獨條目組成。 ACE 包含兩個重要資訊：使用者或群組 SID，以及單一使用者或群組對物件擁有多少存取權限的描述。

CHGRP

....更改檔案的群組 ID ...呼叫 chgrp(1) 的使用者必須屬於指定的群組並且是檔案的擁有者，或具有適當的權限。

莊

...擁有者和群組操作數都是可選的；然而，必須指定一個。如果指定了群組運算元，則其前面必須帶有冒號 (:)。

所有者可以透過數字用戶 ID 或用戶名指定。如果使用者名稱也是數字使用者 ID，則操作數將用作使用者名稱。該組可以是數字組 ID 或組名稱。如果群組名稱也是數字組 ID，則操作數將用作群組名稱。

出於安全原因，檔案的所有權只能由具有適當權限的進程變更。

正如我所讀到的，這意味著如果您的使用者帳戶屬於 Windows 群組，並且該群組具有足夠的權限來修改該群組所擁有的檔案的權限，那麼就可以有效地chgrp在您的使用者帳戶的控制範圍之外存取該文件。這相當於比使用chown顯式user:group參數時的控制要少。在這種情況下，無法聲明user: 和 :group你永遠無法獲得與其他方式相同的結果。

這是一個連結詳細了解 Interix 如何與 Windows ACL 交互，重點關注這些知識如何應用於其他 Unix 變體上的 Samba 檔案系統。

這是一個連結到現在過時的Solaris 文件描述了可調參數rstchown...

指示系統呼叫的 POSIX 語意學是否chown(2)有效...

顯然，如果參數設定為值0...

....關閉 POSIX 語意可能會帶來各種安全漏洞。這也開啟了一種可能性使用者將文件的所有權更改給另一個使用者並且無法檢索該文件無需使用者或系統管理員的干預即可返回。

這樣的選項不會使 Solaris 的POSIX 一致性。僅僅因為它是一個選項，就足以使其成為一致的:

儘管符合 POSIX.1-2008 的所有實作都支援下面描述的所有功能，但可能存在可以刪除或修改的與系統相關或與檔案系統相關的設定過程 任何或所有這些功能。如果需要嚴格遵守，則不應進行此類配置。

以下符號常數應定義為 -1 以外的值。如果常數定義為零值，則應用程式應使用sysconf()、pathconf()、或fpathconf()函數或 getconf實用程式來確定當時系統上或所討論的特定路徑名存在哪些功能。

_POSIX_CHOWN_RESTRICTED

的使用chown()僅限於具有適當權限的進程，並且只能將檔案的群組 ID 變更為該進程的有效群組 ID 或其補充群組 ID 之一。

系統chown()函數 - 這是由雙方進行的記錄的系統調用chown和chgrpshell 實用程式 - 是指定失敗出於多種原因。他們之中：

EACCES 路徑前綴的某個組成部分的搜尋權限被拒絕。

ELOOP 解析路徑參數期間遇到的符號連結中存在循環。

EPERM 有效使用者 ID 與檔案擁有者不匹配，或呼叫進程沒有適當的權限和_POSIX_CHOWN_RESTRICTED表示需要這樣的特權。

然而，授予非 root 使用者權限修改權的行為從來都不是 Solaris 所獨有的。有非常優秀的- 如果有些過時 - Unix 檔案權限的覆蓋範圍這個論壇貼文作者在其中指出：

最初，Unix 允許檔案擁有者放棄檔案。文件的擁有者可以將所有者更改為其他人。非 root 使用者無法撤銷此操作... BSD[之後]chown從非 root 使用者中刪除....[部分原因]...它實現了磁碟配額，這可能會限制用戶在檔案系統中可以擁有的磁碟空間大小...頑皮的用戶可能會放棄大檔案來偷偷超過配額。

今天，很難說非 root 是否可以chown存取文件。許多 Unix 版本都允許兩個都行為...

另一個好的 - 也是最近的 -郵件清單貼文引用此並繼續：

大多數作業系統的預設設定chown僅限於 root 使用者。人們一致認為，出於安全考慮，應該保持這種狀態。如果非 root 使用者確實更改了檔案的擁有者並且任何執行位元處於開啟狀態，則必須清除SUID和位元。SGID這可能會也可能不會發生root。

我認為最後一段說得很好。

該文章還提到了CAP_CHOWN在 Linux 上控制該設施（這應該只影響POSIX_CHOWN_RESTRICTED行為）。還有一種CAP_FOWNER能力，其行為略有不同。

並作為你在2003年指出:

請注意，至少在 HPUX 上，您可以變更檔案的擁有者（root例如）即使您不是特權使用者...

....這取決於配置setprivgroup參數。

在任何情況下，非 root 使用者可以操縱檔案權限，這是可以想像的，例如理由在您的問題中引用，用戶可能chown擁有該用戶擁有的文件，以便該文件由另一個用戶擁有。如果檔案的群組所有權和chown使用者的群組不一致，則使用者將無法再修改該檔案。

在這種情況下chown 然後 chgrp將會失敗，因為用戶將不再有權更改該文件的權限，而chown user:group- 只要團體是用戶自己之中的——就會成功。

有大概許多其他利基情況可能會產生類似的結果，其中可能包括目錄黏和/或設定gid位元、檔案系統和/或特定於實現的存取控制清單。這個線程例如，很有趣。無數的排列遠遠超出了我自己微弱的掌握——這就是為什麼這個答案被維基百科。如果您正在閱讀本文，您相信它值得改進，並且您相信您知道如何 -請這樣做。

還有大量關於文件權限、樹遍歷和符號連結的各種可能影響的文檔，這些影響可能會導致遞歸-R應用程式出現類似的失敗chown：

從POSIX XRAT章節標題第三和第四域:

通常，指定檔案層次結構遍歷選項的使用者希望在單一物理層次結構上進行操作，因此可能引用層次結構以外的檔案的符號連結將被忽略。例如，chownowner file 與指定了 -R 選項的相同命令是不同的操作。在此範例中，此處描述了命令的行為chown owner file，而命令的行為chown -R所有者文件在第三和第四域中描述。

...預設邏輯行走存在安全問題。歷史上，命令chown -R用戶檔案對於超級用戶來說是安全的，因為設定值和設定gid當檔案的所有權變更時，位元會遺失。如果步行是合乎邏輯的，則更改所有權將不再安全，因為使用者可能插入了指向樹中任何檔案的符號連結。同樣，這將需要向執行層次結構遍歷的命令添加一個選項，以不間接通過符號鏈接，並且執行遞歸遍歷的歷史腳本將立即成為安全問題。雖然這對系統管理員來說主要是一個問題，但最好不要為不同類別的使用者設定不同的預設值。

…

在 4.3 BSD 中，chgrp在樹遍歷期間更改了符號連結的群組，而不是目標。 4.4 BSD 中的符號連結沒有所有者、群組、模式或其他標準 UNIX 系統檔案屬性。

以及來自 POSIXchgrp正確的頁面有 this 指向可能不完整的-R遞歸操作，或至少指向什麼用過的成為：

System V 和 BSD 版本使用不同的退出狀態代碼。一些實現使用退出狀態作為發生的錯誤數量的計數；這種做法是行不通的，因為它可能會溢出有效退出狀態值的範圍。標準開發人員選擇透過僅指定 0 和 >0 作為退出值來屏蔽這些。

Question 2

假設1：判斷是否成功的規則chown獨立地檢查目標使用者和群組部分，即它們的形式user_condition(target_uid, other_environment_parameters) && group_condition(target_gid, other_environment_parameters)。

假設2：chown(file, -1, -1)成功。

假設3：判斷是否成功的規則chown與文件目前屬於哪一組無關。

推論：如果chown(file, uid, gid)會成功，那麼也會成功chown(file, -1, gid) && chown(file, uid, -1)。

我不知道有哪個 Unix 變體會違反這些假設，它們看起來相當安全。

這句話看起來像是委員會中的某個人在經過幾個小時的辯論後疲憊不堪時所說的話ps——或者秘書錯誤地轉錄了——並且在審查過程中沒有人發現。畢竟，還有其他充分的理由允許自動更改使用者和群組，包括 POSIX 基本原理中也引用的效能原因，以及原子性（啊，如果只有一個呼叫來更改所有權和權限）。

假設 3 可能錯誤的情況是在一個系統上，進程可以獲得更改檔案擁有者的能力，但前提是他們對檔案具有寫入權限。雖然有些現實，但我不知道有哪個系統是這種情況。然後，chgrp從既不作為 root 也不作為擁有該文件的用戶運行的進程中的一個組可能會使該文件在以後的chown.

對於遞歸調用，存在一些邊緣情況：當單次傳遞成功時，整個傳遞chgrp後跟整個傳遞可能會失敗。chown這不是一個很有說服力的論點，因為它涉及所有者無權遍歷的目錄，並且想要防止所有此類情況的應用程式無論如何都需要擺弄權限。儘管如此，它在技術上滿足了這一基本原理的條件。假設正在運行的進程具有有效的用戶alice、有效的群組staff以及任意更改文件所有者的能力（不僅僅是放棄它們；一些unix變體具有這樣的能力，儘管很少授予非root進程）。

$ ls -ld dir dir/file
d---rwx---  2 charlie  staff        1024 Apr  1  1970 dir
drw-rw----  2 charlie  staff          42 Apr  1  1970 file
$ chgrp -R students dir
$ chown -R bob dir
chown: dir: permission denied

Answer

假設1：判斷是否成功的規則chown獨立地檢查目標使用者和群組部分，即它們的形式user_condition(target_uid, other_environment_parameters) && group_condition(target_gid, other_environment_parameters)。

假設2：chown(file, -1, -1)成功。

假設3：判斷是否成功的規則chown與文件目前屬於哪一組無關。

推論：如果chown(file, uid, gid)會成功，那麼也會成功chown(file, -1, gid) && chown(file, uid, -1)。

我不知道有哪個 Unix 變體會違反這些假設，它們看起來相當安全。

這句話看起來像是委員會中的某個人在經過幾個小時的辯論後疲憊不堪時所說的話ps——或者秘書錯誤地轉錄了——並且在審查過程中沒有人發現。畢竟，還有其他充分的理由允許自動更改使用者和群組，包括 POSIX 基本原理中也引用的效能原因，以及原子性（啊，如果只有一個呼叫來更改所有權和權限）。

假設 3 可能錯誤的情況是在一個系統上，進程可以獲得更改檔案擁有者的能力，但前提是他們對檔案具有寫入權限。雖然有些現實，但我不知道有哪個系統是這種情況。然後，chgrp從既不作為 root 也不作為擁有該文件的用戶運行的進程中的一個組可能會使該文件在以後的chown.

對於遞歸調用，存在一些邊緣情況：當單次傳遞成功時，整個傳遞chgrp後跟整個傳遞可能會失敗。chown這不是一個很有說服力的論點，因為它涉及所有者無權遍歷的目錄，並且想要防止所有此類情況的應用程式無論如何都需要擺弄權限。儘管如此，它在技術上滿足了這一基本原理的條件。假設正在運行的進程具有有效的用戶alice、有效的群組staff以及任意更改文件所有者的能力（不僅僅是放棄它們；一些unix變體具有這樣的能力，儘管很少授予非root進程）。

$ ls -ld dir dir/file
d---rwx---  2 charlie  staff        1024 Apr  1  1970 dir
drw-rw----  2 charlie  staff          42 Apr  1  1970 file
$ chgrp -R students dir
$ chown -R bob dir
chown: dir: permission denied

chown(1) POSIX 規範的解釋

答案1

答案2

相關內容