UID / GID 沒過時，它只是被放在很多人看不到、但不能出錯的那一層

 

為什麼系統還在用 UID / GID？

從作業系統到現代應用權限設計的正確分工

在做系統開發或後端服務時，我們很常聽到 UID / GID 這兩個名詞，但也常會產生疑問：

• 這不是很古老的 Unix 設計嗎？

• 現在都有 RBAC、OAuth、JWT 了，還需要它嗎？

• 為什麼 Docker、Kubernetes 反而更重視 UID？

這篇文章會從工程實務角度，說清楚：

UID / GID 是什麼、為什麼還存在，以及它在現代系統中該扮演的正確角色

一、UID / GID 是什麼？（不是帳號名稱）

UID（User ID）

UID 是作業系統內部用來識別「使用者身分」的數字編號。

例如在 Linux 中：

root      → UID 0
www-data  → UID 33
jeff      → UID 1001 

雖然我們平常看到的是帳號名稱，但 Kernel 實際只認 UID，不認名稱。

GID（Group ID）

GID 則是群組的身分識別碼，用來表示「你屬於哪些群體」。

一個使用者通常會有：

• 一個 主要群組（Primary Group）

• 多個 附加群組（Secondary Groups）

二、為什麼作業系統要用「數字」？

這是一個很重要、但常被忽略的設計核心。

1️⃣ 效能與簡單性

數字比較快、比較小、比較好比對，對 Kernel 來說是最直接的表示方式。

2️⃣ 穩定性

帳號名稱可以改，但 UID 通常不變。

jeff → jeff.chen → jchen
UID 還是 1001

3️⃣ 分散式與跨系統相容

在 NFS、Container、Volume 掛載時：

只要 UID 對齊，權限就對齊

這點在 Docker / Kubernetes 中尤其重要。

三、檔案權限其實只看 UID / GID

當你看到：

-rwxr-x---

實際上系統紀錄的是：

owner_uid = 1001
group_gid = 1002
permission_bits

帳號名稱只是顯示用，權限判斷完全是數字比對。

四、UID / GID 的優點與限制

✅ 優點（它為什麼活了幾十年）

✔ 穩定到不能再穩定

• Unix 時代設計

• Linux、BSD、macOS 全通用

✔ 非常適合「底層安全隔離」

• Process 權限

• 檔案系統

• Container 隔離

✔ 容器化時代反而更重要

Container A UID 1000
Container B UID 1000
共享 Volume 不會亂

---

❌ 缺點（也是很多人誤用的原因）

✘ 語意太弱

UID 1001 能做什麼？
→ 系統不知道

✘ 不適合業務邏輯

UID 無法表達：

• 角色（Admin / User）

• 權限（Read / Write）

• 條件（只能看自己的資料）

✘ 管理成本高

跨系統 UID 沒規劃好，會變成權限地獄。

五、那現代系統到底還用不用 UID / GID？

答案是：一定用，但只在底層

正確分層來看：

系統層級	是否使用 UID / GID	說明
作業系統（Kernel / OS）	✅ 必用	行程、檔案、資源存取的最底層安全隔離機制
Container / VM	✅ 必用	確保容器之間的檔案與行程權限正確隔離
檔案系統	✅ 必用	透過 owner / group / permission bits 控制存取權限
Web / API 層	❌ 幾乎不用	使用 Token、Claims、UserId（非 UID）來識別使用者
業務權限邏輯	❌ 不該使用	應使用 RBAC / ABAC / Policy-based 權限模型

六、那「現在用什麼來管權限」？

1️⃣ RBAC（角色權限模型）

最常見、最好理解：

User → Role → Permission

例如：

jeff → Admin → order:write

---

2️⃣ ABAC（屬性條件）

更進階的做法：

部門 = IT
且 時間 < 18:00

---

3️⃣ OAuth / JWT / Claims

在 API 世界中，權限通常長這樣：

{
  "sub": "user-uuid",
  "roles": ["admin"],
  "scopes": ["order:write"]
}

👉 完全不需要知道 UID

七、正確的現代系統權限分工

✔ 建議架構

OS / Container
 └── UID / GID（安全隔離）

Application
 └── UserId（UUID / Snowflake）
     └── Role / Permission / Policy

❌ 常見錯誤設計

• 把 Linux 群組當業務角色

• 用 UID 當系統使用者主鍵

• 用 chmod 控制 API 權限