🐧 Linux 使用者與權限進階指南：useradd、群組管理與 ACL 實戰
在單機桌機上，很多人只會建立一個帳號，權限問題好像不明顯；但在 多人共用、同時跑多個服務的 Linux 伺服器 上， 使用者與權限設計就會直接影響到安全性與維運效率。
本篇文章以「百科級」的深度，完整說明 Linux 的 身分模型（User / Group / Others）、 使用者與群組管理、傳統檔案權限， 以及更進階的 ACL（Access Control List）實戰應用。 你可以把這篇當成：建立一台多人共享 Linux 伺服器之前，必讀的權限設計指南。
一、Linux 的身分與權限模型概念
在操作指令之前，先弄懂幾個關鍵名詞：
- UID（User ID）：每個帳號背後都有一個數字 ID。
- GID（Group ID）：每個群組也有一個 ID。
- user / group / others：檔案權限分成三組身分。
- root：UID 為 0 的超級使用者，幾乎可以做任何事情。
- shell：/bin/bash、/bin/zsh… 使用者登入後操作的環境。
可以用 id 指令看看自己目前的身分：
id
id <username>輸出大致像這樣：
uid=1000(wwfandy) gid=1000(wwfandy) groups=1000(wwfandy),27(sudo),999(docker)- uid=1000：使用者 ID。
- gid=1000：主要群組 ID。
- groups=...：附加群組（補充權限的重要來源）。
Linux 設計的核心精神是：一切皆檔案、所有操作都必須經過權限檢查。 包含檔案、目錄、裝置節點、Socket、Pipe，都有擁有者與權限設定。
二、重要的帳號與群組相關系統檔
使用者與群組資訊主要儲存在這幾個檔案：
/etc/passwd：帳號基本資料（名稱、UID、GID、家目錄、預設 shell）。/etc/shadow：密碼雜湊與密碼政策（只有 root 看得到）。/etc/group：群組名稱與 GID，以及成員列表。
可以用 getent 指令查詢：
getent passwd wwfandy
getent group sudo
建議避免直接手改這些檔案，除非非常熟悉格式；大多數情況請使用
useradd、usermod、groupadd 等指令進行管理。
三、使用者帳號管理：useradd / passwd / usermod / userdel
1. 新增一般使用者
最常見的情境：為同事或服務建立一個新的帳號。
# 建立新帳號 alice，並建立家目錄 /home/alice
sudo useradd -m alice
# 設定密碼
sudo passwd alice
某些發行版（例如 Debian/Ubuntu）會偏好使用 adduser 這個比較親切的互動式包裝指令，
但底層還是呼叫 useradd。
2. 常用 useradd 參數
sudo useradd -m -s /bin/bash -c "專案A 開發者" alice-m：自動建立家目錄。-s：指定預設 shell。-c：備註欄位（在 /etc/passwd 的 GECOS）。-u：自訂 UID（特殊情境才需要）。
3. 修改帳號屬性：usermod
# 把 alice 的預設 shell 改成 zsh
sudo usermod -s /bin/zsh alice
# 把 alice 加到 sudo 群組（附加群組）
sudo usermod -aG sudo alice
其中 -aG 非常重要：-a 代表「append」，沒有這個會覆蓋掉使用者原有的附加群組。
4. 刪除帳號：userdel
# 僅刪除帳號，保留家目錄
sudo userdel alice
# 刪除帳號並連同家目錄一起移除（請謹慎）
sudo userdel -r alice
在正式環境建議先鎖定帳號（passwd -l 或停用登入），觀察一段時間確認沒有服務依賴後，
再決定是否清除家目錄。
四、群組管理：groupadd / gpasswd 與 primary / supplementary groups
Linux 的權限多半是「使用者 + 群組」一起設計。 一個使用者通常會有：
- 主要群組（primary group）：在 /etc/passwd 中記錄的那個 GID。
- 附加群組（supplementary groups）：額外被加進去的群組。
1. 新增群組
# 建立一個專案群組 projectA
sudo groupadd projectA2. 把使用者加入群組
# 讓 alice 加入 projectA
sudo usermod -aG projectA alice
# 也可以用 gpasswd 管理
sudo gpasswd -a alice projectA3. 檢查群組
id alice
getent group projectA實務上很常見的做法是：每一個專案建立一個群組，再將需要權限的人全部加進該群組， 如此不需要對每個檔案逐一設定多個帳號，只要使用者有「群組身分」即可。
五、傳統檔案權限：rwx / chmod / chown / chgrp
1. ls -l 權限欄位解讀
ls -l
-rw-r----- 1 alice projectA 4096 Nov 15 10:00 report.txt
drwxrws--- 2 root projectA 4096 Nov 15 09:00 /srv/projectA- 第 1 個字元：檔案類型（- 一般檔案、d 目錄、l 軟連結…）。
- 後面 9 個字元分成三組：user / group / others 的 rwx。
- 上例
-rw-r-----表示：- 擁有者（alice）：讀寫。
- 群組（projectA）：讀。
- 其他人：沒有任何權限。
2. chmod 數字與符號用法
# 數字表示法：owner/group/others
chmod 640 report.txt
# 符號表示法：u/g/o/a + +/-/=
chmod g+w report.txt # 給群組寫入權限
chmod o-r report.txt # 拿掉其他人的讀取權限
chmod a-x script.sh # 所有人都不能執行3. chown 與 chgrp：調整檔案擁有者與群組
# 改變檔案擁有者與群組
sudo chown alice:projectA report.txt
# 僅變更群組
sudo chgrp projectA report.txt對於專案目錄，可以一次調整整棵目錄結構：
sudo chown -R root:projectA /srv/projectA4. setgid 與目錄繼承群組
對於「多人共用的專案目錄」，很常會搭配目錄的 setgid 位元：
sudo chmod 2770 /srv/projectA # 2 代表 setgid這樣，在 /srv/projectA 底下新建立的檔案，群組會自動繼承為 projectA， 而不是各使用者自己的主要群組。這是協作環境中很重要的一個細節。
六、為何需要 ACL？傳統權限的限制
傳統的 rwx 權限模型，對象只有三類：user / group / others。 在某些情境會不太夠用，例如：
- 專案群組 projectA 想共用資料夾，但只想額外開放「只讀」給 audit 帳號。
- 某個檔案需要同時讓兩個群組可讀寫（例如 dev 與 ops）。
如果只靠傳統權限，常常需要硬切群組或建立額外複雜的目錄結構。 這時候就可以使用 ACL（Access Control List） 來做更細緻的控制。
常見指令：
getfacl：查看 ACL。setfacl：設定 ACL。
確認檔案系統有支援 ACL（大部分 ext4、xfs 預設都支援）：
mount | grep -E 'ext4|xfs'
# 如果有看到 acl 選項，就代表已啟用 ACL 支援七、ACL 實戰：針對特定使用者與群組細緻授權
1. 對特定使用者開放讀取權限
假設：
/srv/projectA是專案目錄。audit帳號需要只讀權限檢視檔案。
# 先確保基本權限不對 others 開放
sudo chmod -R 770 /srv/projectA
# 對使用者 audit 開放「讀取與執行」（X 表示目錄可進入）
sudo setfacl -R -m u:audit:rx /srv/projectA
# 查看 ACL
getfacl /srv/projectA輸出範例：
# file: srv/projectA
# owner: root
# group: projectA
user::rwx
user:audit:rx
group::rwx
mask::rwx
other::---這代表除了群組 projectA 的成員以外，audit 也額外被授權可讀取內容， 而其他人（others）依然沒有任何權限。
2. 對整個目錄設定「預設 ACL」
如果只設定單一檔案的 ACL，新建立的檔案不會自動套用。 因此在目錄上常會再設定一組 default ACL：
sudo setfacl -R -m u:audit:rx /srv/projectA
sudo setfacl -R -m d:u:audit:rx /srv/projectA
d: 代表 default ACL，會套用到未來在此目錄底下新建立的檔案或目錄。
3. 同時給多個群組權限
另一個常見案例：開發團隊 dev 與營運團隊 ops 都需要寫入權限。
sudo mkdir -p /srv/shared
sudo chown root:dev /srv/shared
sudo chmod 2770 /srv/shared # 基礎權限給 dev
# 額外給 ops 群組讀寫權限
sudo setfacl -m g:ops:rwx /srv/shared
sudo setfacl -m d:g:ops:rwx /srv/shared這樣只要使用者是 dev 或 ops 的成員，就可以在 /srv/shared 裡自由協作， 大幅減少「為了權限」而被迫複製一堆資料夾的情況。
八、完整範例：建立一個安全的專案協作環境
綜合前面內容，我們設計一個實戰情境：
- 專案名稱：
projectA - 開發者：alice、bob
- 稽核者：audit（只讀）
- 專案資料夾：
/srv/projectA
步驟 1：建立群組與使用者（若尚未建立）
sudo groupadd projectA
sudo useradd -m alice
sudo useradd -m bob
sudo useradd -m audit
sudo passwd alice
sudo passwd bob
sudo passwd audit步驟 2：把開發者加入 projectA 群組
sudo usermod -aG projectA alice
sudo usermod -aG projectA bob步驟 3：建立專案目錄，設定擁有者與群組
sudo mkdir -p /srv/projectA
sudo chown root:projectA /srv/projectA
sudo chmod 2770 /srv/projectA # setgid + 770如此一來，專案裡的檔案預設由 root 擁有，群組為 projectA，只有專案群組成員看得到， 並避免誤把權限開放給 others。
步驟 4：使用 ACL 給 audit 只讀權限
sudo setfacl -R -m u:audit:rx /srv/projectA
sudo setfacl -R -m d:u:audit:rx /srv/projectA現在，我們完成一個符合實務需求的權限設計：
- alice / bob：可在 /srv/projectA 內讀寫與建立檔案。
- audit：可遍歷與閱讀所有內容，但不能修改。
- 其他帳號：沒有任何權限。
九、常用檢查與除錯技巧
遇到「為什麼我不能讀 / 寫這個檔案？」這類問題時，可以依序檢查：
- 確認身分：
id看看自己有哪些群組。 - 查看檔案權限：
ls -l看傳統 rwx。 - 查看 ACL：
getfacl <檔案或目錄>。 -
模擬以某個使用者執行（需要 sudo）：
sudo -u alice ls /srv/projectA
如果是目錄層級的權限問題，記得要一路往上檢查，例如
/srv 本身是否對該使用者有「執行（x）」權限，否則即使底下目錄開得再大也進不去。
十、安全與維運建議：把權限設計成一套標準
最後整理幾個實務上非常重要的原則，建議在自己或團隊的伺服器 SOP 中固定下來：
-
原則 1：避免以 root 直接登入
使用 sudo 委派管理權限，並記錄在 sudo log 裡，比較容易稽核。 -
原則 2：一個服務一個帳號
例如 web、db、backup 分別用 www-data、postgres、backupuser 等， 發生問題時比較好切割權限與風險。 -
原則 3：專案導向的群組設計
每個專案建立一個群組（projectA、projectB…），使用者透過群組獲得權限，而不是直接給個別帳號。 -
原則 4：敏感資料一律關閉 others 權限
設定為 750、770、700 類型的權限，並搭配 ACL 給需要的人精準授權。 -
原則 5：定期檢查例外 ACL
ACL 很強大，但也容易被遺忘。建議定期掃描關鍵目錄，整理出「誰多了哪些特別權限」。
當你把「帳號建立、群組分配、目錄結構、初始權限、ACL 規則」這幾件事整理成一套 標準流程（SOP） 之後，新專案、新同事加入都可以快速複製同樣的安全水準， 也讓未來的維運、稽核與問題排查更加清楚。
✅ 如果你已經熟悉本文的 useradd、群組與 ACL 觀念，下一步可以搭配 SSH 安全強化、備份與日誌監控 一起設計出完整的 Linux 伺服器安全基準（Baseline）， 讓每一台新上線的主機都符合同樣的安全與權限政策。
沒有留言: