在許多系統上,根使用者 (root user) 和超級使用者 (superuser) 都擁有完整的系統控制權。UNIX 應用程式子系統 (SUA) 並無法識別根使用者。在開發「可攜式作業系統介面 (POSIX)」標準時,根使用者的概念是視為系統管理問題來處理。POSIX 標準會針對某些作業定義適當的特殊權限,而不會以根使用者為基礎來設定特殊權限。

在本主題中

setuid 與 setgid

setuidsetgid 機制允許程式在執行時,考量有別於程式執行者的安全性原則層面。它們允許程式在呼叫使用者與其他安全性原則之間切換這些層面。

這是適當的特殊權限區別起點。當 setuidsetgid 機制可允許應用程式控制問題的答案:「您是誰?」時,適當的特殊權限將回答:「您可以做什麼?」

UNIX 應用程式子系統與識別身分

在典型的 UNIX 環境中,只有一位使用者會被授與全部的特殊權限。該使用者通常稱為 root (根),且具有 uid == 0。在 UNIX 應用程式子系統中,給定系統上所有支援的特殊權限都會授與屬於該系統上 Administrators 群組或 Domain Administrators 群組之成員的使用者。您不需要以系統管理員身分登入。在 Administrators 群組或 Domain Administrators 群組中具有成員資格的任何使用者,都可以處理 root 特殊權限。並非 POSIX 或 UNIX 中定義的所有特殊權限都可以在 SUA 中使用,換句話說,某些特殊權限並未授與任何使用者。

通常,有多種動作需要適當的特殊權限。這些包括存取檔案系統、傳送信號給其他處理程序 (處理程序控制),或是變更處理程序的有效使用者識別元 (UID) 或群組識別元 (GID),以變更該處理程序執行某些動作的能力。

根據 POSIX 標準,檔案具有併入位元以設定 UID (setuid) 和設定 GID (setgid) 的權限。如果對檔案設定其中某個或兩個位元,則當處理程序執行該檔案時,處理程序會取得檔案的 UID 或 GID。如果小心使用,此機制可允許無特殊權限的使用者執行需要透過檔案擁有者或群組的更高特殊權限才可執行的程式。不過,如果不正確使用,則可能導致安全性風險,使得無特殊權限的使用者可以執行應該只能由系統管理員執行的動作。基於這個原因,SUA 預設為不支援此機制。相反地,如果您試圖執行已經設定 setuidsetgid 位元的檔案,SUA 將不會執行檔案,並且傳回錯誤碼 ENOSETUID

UNIX 應用程式子系統中的 Setuid 設定考量

如果您依賴需要標準 POSIX 行為的應用程式,可以設定 SUA 來執行已經設定 setuidsetgid 位元的檔案。如果是以這種方式來設定 SUA,當處理程序執行已經設定 setuidsetgid 位元的檔案時,SUA 將以指派給檔案擁有者或群組的特殊權限,為處理程序建構本機安全性權杖。因為權杖屬於本機,所以網路上的其他電腦無法識別它們。這表示,例如,即使檔案是由 Domain Administrators 群組的成員所擁有,處理程序仍不會具有透過 Microsoft(R) Windows(R) 網路來存取網域中其他電腦的受信任存取權。相反地,特殊權限只有在執行處理程序的電腦上才會生效。

例如,某個處理程序會執行已經設定 setuid 位元且為 Domain Administrators 群組之成員所擁有的檔案。如果該程式嘗試變更網域使用者的密碼,該嘗試將會失敗,因為處理程序的安全性權杖屬於本機,因此使得網域中的其他電腦無法識別。另外,如果程式嘗試變更本機使用者的密碼,嘗試將會成功,因為檔案的擁有者是 Domain Administrators 群組的成員,而它通常屬於本機電腦的 Administrators 群組。如需如何設定 SUA 執行已經設定 setuidsetgid 位元之檔案的相關資訊,請參閱附隨於下載套件「以 UNIX 為基礎的應用程式之公用程式及軟體開發套件 (SDK)」的說明檔。

對於 setuid(2)setgid(2)chroot(2) 功能,處理程序必須擁有對應回系統帳戶的有效 UID、本機網域的系統管理員帳戶或主體網域的系統管理員帳戶。本機系統管理員帳戶僅可在同一網域中,將 UID 或 GID 變更為其他識別碼。

chown(1)chmod(1)chgrp(1),帳戶必須擁有 Windows 特殊權限 SE_BACKUP 和 SE_RESTORE,才能夠對其他使用者或群組擁有的檔案執行 make 操作,或者修改其他使用者擁有的檔案權限。這些權限通常屬於系統管理員和備份操作員帳戶。

請參閱