你有沒有遇到過這種情況明明chmod 777都給了用戶還是報“權限不足”或者刪不掉一個文件ls -l一看自己明明有w權限卻提示Operation not permitted。如果你對這些現象背后的邏輯一知半解那這篇關于 Linux 基本權限的梳理應該能幫你把整條線串起來。我最早是從 Windows 帶過來的習慣總覺得權限就是“勾選一下”那么簡單后來真上了生產環(huán)境被rwx、屬主、屬組這些概念折騰了好幾回才慢慢摸清楚。這篇文章我不會照抄手冊而是按照我自己排查問題、設計權限方案時的思考路徑來寫先講清楚rwx在文件和目錄上的本質區(qū)別再拆解chmod/chown/chgrp實操中的易錯點接著延伸到 SUID/SGID/Sticky Bit 這套特殊權限機制然后聊聊 umask 對默認權限的影響最后補上 ACL、root 與排查流程。無論你是剛接觸 Linux 的新手還是需要處理服務器權限問題的一線運維這篇都值得花十幾分鐘過一遍。1. rwx 三元組文件與目錄的權限語義完全不同1.1 權限位到底是給誰看的Linux 的權限模型本質上是給“三類身份”分別設置“三種操作能力”。三類身份分別是文件的屬主owner常用u表示、屬組group常用g表示、其他人others常用o表示。三種操作能力就是讀readr、寫writew、執(zhí)行executex。用ls -l查看一個文件時第一列那 10 個字符就是權限的“門牌”-rwxr-xr-- 1 root root 1234 Feb 14 10:00 test.sh第一個字符表示文件類型-是普通文件d是目錄l是軟鏈接。后面 9 個字符每 3 個一組分別對應屬主、屬組、其他人的權限。上面的例子就是屬主可讀可寫可執(zhí)行屬組可讀可執(zhí)行其他人只可讀。很多新手會背“r4w2x1加起來是 7”但為什么是這個數字這里我建議你用二進制的思路去理解每個權限位其實就是一個 bit1 代表有權限0 代表沒有。rwx對應二進制111轉成十進制正好是 7rw-對應110是 6r--是100是 4。這么一想chmod 755和chmod 754就不再是魔法數字了而是“我想把哪些 bit 打開”的直觀表達。1.2 目錄的 w 權限才是“刪除文件”的關鍵這里我必須先講一個最容易被誤解的點一個文件能不能被刪除取決于它所在目錄的寫權限而不是文件自身的寫權限。很多人第一次遇到這種情況都會懵我明明對文件有rw權限怎么rm的時候系統告訴我“Permission denied”原因很簡單rm這個操作本質上不是在“修改文件”而是在“修改目錄的目錄項”。你要把文件名從目錄的列表里摘掉操作系統檢查的是你對這個目錄有沒有寫權限。所以如果你對某個文件只有r權限但對它所在目錄有w權限你依然可以把這個文件刪掉。目錄的r權限決定你能不能列出目錄里的文件名lsx權限決定你能不能進入目錄cd以及能否訪問其中文件。這里有個更隱蔽的坑如果你對一個目錄只有r權限而沒有x權限那ls確實能看到文件名但當你嘗試訪問文件內容或使用stat查看詳細信息時系統可能報錯。因為x權限在目錄上的語義是“可通行”沒有它你對目錄內容的訪問無法“深入”。1.3 文件權限的“重命名與硬鏈接”邊界既然說到目錄寫權限的重要性順便提一個和重命名、硬鏈接相關的知識點。重命名文件同樣屬于修改目錄項的操作所以能否重命名也取決于目錄權限而不是文件權限。硬鏈接是另一個容易讓人疑惑的地方。硬鏈接的本質是在另一個目錄里新增一個目錄項指向同一個 inode。因此創(chuàng)建硬鏈接時你不能跨文件系統而且通常需要你對目標目錄有寫權限。如果你在一個目錄里嘗試給別人的文件創(chuàng)建硬鏈接但該目錄沒有w權限一樣會失敗。我把文件與目錄的權限語義差異整理成一個對照表方便你記憶權限位文件語義目錄語義r讀取文件內容列出目錄中的文件名lsw修改文件內容在目錄中創(chuàng)建、刪除、重命名文件x將文件作為程序執(zhí)行進入目錄cd訪問目錄內文件常見坑修改文件用 w執(zhí)行用 x刪除文件看目錄 w進入目錄看 x2. chmod / chown / chgrp 實操拆解命令背后的易錯點2.1 chmod 數字法與符號法各自的應用場景chmod是調整權限最常用的命令它有兩種寫法對應不同習慣。數字法的好處是簡潔、可批量chmod 750 script.sh這句命令把script.sh設置為屬主rwx屬組r-x其他人無權限。它特別適合在腳本里批量處理或者按固定的權限模板給一批文件套用。符號法的好處是精確、不用心算chmod ux script.sh # 給屬主加執(zhí)行權限 chmod g-w,o-r file.txt # 屬組去掉寫權限其他人去掉讀權限 chmod ar file.txt # 給所有人加讀權限我自己的經驗是交互式操作時用符號法居多因為不需要做加法但在批量部署腳本、需要把權限狀態(tài)固化下來的場景用數字法更穩(wěn)妥。有一點要特別注意用數字法給目錄賦值時chmod -R 755 /some/dir會把目錄下所有文件也統一改成755但有些可執(zhí)行文件并不需要被“所有人執(zhí)行”這一下可能把權限面放大。謹慎的做法是先find區(qū)分文件和目錄再分別處理或者用下面的chmod參數來區(qū)分操作對象chmod -R urwX,gorX /some/dir注意大寫X它表示“僅當目標本身已是目錄或已有執(zhí)行權限的文件時才賦予執(zhí)行權限”。這條命令在實際部署中非常實用它能避免可執(zhí)行位被無腦放大。2.2 chown 和 chgrp修改歸屬時的身份限制chown用來改屬主chgrp用來改屬組?，F代 Linux 里我一般直接用一條chown同時改兩者格式是屬主:屬組chown alice:developers project/ chown -R alice:developers project/幾個容易踩的坑第一普通用戶通常不能把自己的文件chown給別人只有 root 能做。這個限制是內核級別的目的是防止用戶通過“把文件丟給 root”來繞開配額或審計。如果遇到Operation not permitted先反省一下是不是沒加 sudo。第二chown會同時清除文件的 SUID/SGID 特殊權限位。原因很好理解切換屬主之后原來的 SUID 語義可能形成權限提升漏洞內核出于安全考慮直接把這些位清掉。所以如果你發(fā)現某個程序在執(zhí)行chown后特殊權限丟了這不是 bug是保護機制。第三chgrp雖然單獨存在但功能其實被chown user:group覆蓋了。你可以把文件屬組改成你所在的任何組但不能改成你不在的組除非有 root 權限。2.3 實戰(zhàn)案例從零搭建一個團隊共享目錄這里我以一個常見的需求為例演示完整的權限設計過程。場景服務器上有一個/data/team_project目錄團隊成員都在devteam組中要求組內成員可以讀、寫、進入但不能隨意刪除別人的文件其他用戶完全不可見。第一步創(chuàng)建目錄并設置屬組sudo mkdir -p /data/team_project sudo chown root:devteam /data/team_project sudo chmod 2770 /data/team_project這里2770的前置2是 SGID 位。目錄設置了 SGID 后所有在目錄內新建的文件/子目錄會自動繼承目錄的屬組devteam而不是創(chuàng)建者的主組。這一步對團隊協作至關重要否則新文件可能帶著個人主組其他組員就沒有訪問權限了。第二步讓子目錄也繼承組并限制刪除他人文件sudo chmod gs /data/team_project/subdir其實只要你設置目錄時用了帶 SGID 的2770新建的子目錄多數發(fā)行版會自動帶上 SGID。但如果你用mkdir手動建了子目錄還是檢查一下。第三步測試實際效果。以兩個不同用戶比如alice和bob分別登錄嘗試創(chuàng)建文件、修改文件、刪除對方文件。你會發(fā)現在這個目錄里大家都能讀寫但能否刪別人的文件取決于目錄是否還開啟了 sticky bit。上面例子中沒有設置 sticky bit所以組員是可以相互刪除文件的如果你希望只能刪自己的文件就把權限設為3770SGID Sticky Bit。這個案例的完整邏輯是需求對應的權限設計組成員可讀寫進入屬組權限rwx其他人不可訪問others 權限為 0新文件自動歸屬組成目錄設 SGID防止隨意刪除他人文件目錄加 Sticky Bit3. 特殊權限位SUID、SGID 與 Sticky Bit 的實際用途3.1 SUID為什么普通用戶能改自己的密碼先看一條命令ls -l /usr/bin/passwd # -rwsr-xr-x 1 root root 59976 Feb 6 2024 /usr/bin/passwd注意到屬主權限里的rws了嗎這個s就是 SUIDSet User ID位。它的作用是當一個帶有 SUID 的程序被執(zhí)行時進程的有效用戶 IDeffective UID會切換為該程序屬主的 ID而不是執(zhí)行者的 ID。passwd命令的屬主是 root所以普通用戶執(zhí)行它時進程以 root 身份運行才有權限去修改/etc/shadow這個只有 root 能寫的密碼文件。這是 Linux 里最典型的 SUID 應用也是理解“最小權限原則被打破”的經典案例。用數字法設置 SUID是在原有三位權限前加4例如chmod 4755 some_program對應ls -l顯示為-rwsr-xr-x。這里我要給一個強烈建議永遠不要輕易給自定義腳本設置 SUID尤其是那些可以被其他用戶調用的腳本。SUID 是權限提升的“高壓電”一旦腳本能被普通用戶觸發(fā)并執(zhí)行幾乎等于把 root 鑰匙交了出去。排查安全問題時find / -perm -4000是檢查系統里所有 SUID 文件的常用命令建議定期看一遍。3.2 SGID目錄協作場景里的“組繼承器”SGIDSet Group ID有兩種作用方式。用在可執(zhí)行文件上時進程的有效組 ID 會切換為文件屬組用在目錄上時所有在該目錄下新建的文件和子目錄都會自動繼承該目錄的屬組。團隊共享場景下SGID 的價值非常大。假設/data/team_project屬組是devteam且開啟了 SGID那么alice在內創(chuàng)建文件時文件的組會自動變成devteam而不是alice的主組比如alice。這樣其他組員才能順利按組權限訪問。設置目錄 SGID 的命令chmod gs /data/team_project # 等價于 chmod 2770 /data/team_project檢查目錄是否生效可以用ls -ld看權限位是否有sls -ld /data/team_project # drwxrws--- 2 root devteam 4096 Feb 14 10:30 /data/team_project注意SGID 在文件和目錄上的表現不同這是面試和實際排錯都愛考的點文件上是“運行時切換組身份”目錄上是“新建內容繼承屬組”。3.3 Sticky Bit/tmp 的防誤刪設計Sticky Bit 用在目錄上時含義是即使目錄本身允許所有用戶寫用戶也只能刪除或重命名自己擁有的文件不能動別人的文件。典型例子就是/tmpls -ld /tmp # drwxrwxrwt 20 root root 4096 Feb 14 10:35 /tmp權限位最后的t就是 sticky bit對應數字法中的1所以設置方式是chmod 1777 /tmp/some_shared_dir如果你在一個多人可寫的共享目錄里想防止用戶互相刪文件這個 bit 是首選方案。結合上一節(jié)的團隊案例3770SGID Sticky Bit的組合非常常見。需要留意的是Sticky Bit 只影響“刪除/重命名”操作不影響“修改內容”。也就是說bob不能刪alice的文件但如果有寫權限他依然可以打開alice的文件清空內容。要真正防止內容被篡改得結合 ACL 或更細粒度的權限模型。4. umask 與默認權限新文件為什么一出生就帶著某個權限4.1 umask 不是“減掉的權限”而是“屏蔽掉的權限位”很多資料把 umask 簡單解釋為“創(chuàng)建文件時默認減掉的權限”比如umask 022時新建文件權限是666 - 022 644新建目錄是777 - 022 755。這個說法在大部分場景下能對上但本質上umask 是按位取反后的“掩碼”它決定的是創(chuàng)建文件時哪些權限位會被強制清零。為什么新文件默認不是666、新目錄不是777因為普通文件不應該默認獲得執(zhí)行權限除非程序顯式要求比如腳本編譯出來的二進制所以系統把基礎權限設成了666而目錄為了可進入基礎權限是777。當 umask 為022時文件666去掉022的置位位得到644即rw-r--r--目錄777去掉022的置位位得到755即rwxr-xr-xumask 值越“大”默認權限越“小”。安全場景里很多人會把自己的 umask 設為077這樣新建文件只有屬主才能讀屬組和其他人一點權限都沒有。查詢當前 umaskumask臨時修改umask 077持久化修改的話一般寫在~/.bashrc或/etc/profile中。如果是要影響所有用戶的登錄環(huán)境系統管理員通常會在/etc/profile、/etc/bashrc或/etc/profile.d/下的腳本里設置全局默認值。4.2 實戰(zhàn)不同角色定制默認權限我曾經給一臺多人開發(fā)機設置過默認權限需求是所有開發(fā)人員創(chuàng)建的文件默認讓同組可讀但不能寫部分管理員目錄希望文件默認同組可寫。思路是給不同用戶設置不同的 umask。開發(fā)人員的~/.bashrc里加umask 022這樣新建文件644同組可讀不可寫。對于需要協作編輯的目錄也可以考慮用chmod gw在目錄級別放開寫權限不過要注意這會讓所有能進入該目錄的組員都能改你的文件。若想更精確建議用 ACL見下一節(jié)。這中間有個常見問題明明 umask 寫好了新建文件權限還是不對。排查思路是確認當前 shell 的 umaskumask -S確認是否有/etc/profile、~/.profile、~/.bash_profile、~/.bashrc里多處設置后執(zhí)行的會覆蓋先執(zhí)行的檢查程序本身是否顯式調用了open()并指定權限參數比如mkdir(path, 0755)這類寫死的模式umask 只是對它做“減掩碼”處理無法讓它變大umask 和進程的關系值得多說一句umask 是 shell 的內建狀態(tài)子進程會繼承。所以你在一個終端里改了 umask在這個終端里啟動的所有程序創(chuàng)建文件都會受影響但其他終端、系統服務則不會。5. 進階場景ACL、root 與權限排查思路5.1 ACL當基本權限不夠用時基本權限模型只有屬主、屬組、其他人三檔在真實項目中經常不夠用。比如你想讓alice對/data/project有只讀權限但alice既不是屬主也不在屬組里按傳統權限模型就得改屬組或把 everyone 放行副作用很大。這時候就該上 ACLAccess Control List了。查看文件 ACLgetfacl /data/project給指定用戶添加權限setfacl -m u:alice:r /data/project給指定組添加權限setfacl -m g:devteam:rw /data/project刪除指定用戶權限setfacl -x u:alice /data/project設置了 ACL 后ls -l顯示的權限位末尾會多一個drwxrwx--- 2 root devteam 4096 Feb 14 10:40 /data/project此時真正生效的權限組合要以getfacl的輸出為準不能只看ls -l的傳統三位權限。ACL 還有一個很有用的特性mask。mask 限制了所有“命名的用戶/組”在 ACL 中能拿到的最大權限。比如 mask 為r-x那即使setfacl -m u:alice:rwxalice實際也只能拿到r-x。這也是實際排錯時容易翻車的地方——ACL 明明給了權限用戶卻依然進不去。默認 ACLdefault ACL只對目錄有效設置后新建的文件會自動繼承相應的 ACL 條項。這個特性很適合團隊目錄不用再擔心新文件掉權限。5.2 root 的特殊性與 sudo 的邊界root 在傳統 Linux 權限模型里幾乎是“無法無天”的不管文件權限是000還是r--root 都能讀不管目錄是否可寫root 都能刪文件。內核里專門有一段邏輯檢查當前用戶是否是 rootUID 0是的話基本跳過大部分權限判斷。但有兩個細節(jié)不要誤解。第一root 也不是絕對無敵的面對只讀文件系統、SELinux 強制策略、nosuid掛載選項等root 同樣受限。第二sudo -u切換用戶執(zhí)行命令時權限判斷按目標用戶來算不會因為用了 sudo 就自動變成 root 權限除非目標用戶就是 root。生產環(huán)境的原則是“能不用 root 就不用”。通過 sudo 按需授權命令白名單控制在/etc/sudoers里。這里我給出一個排查權限問題時常用的命令棧id # 當前用戶、UID/GID、附加組 ls -ld /data/project # 傳統權限位 getfacl /data/project # ACL 詳細規(guī)則 mount | grep /data # 掛載選項是否包含 noexec/nosuid/ro getenforce # SELinux 是否啟用及模式如果權限問題還是沒解決最容易被忽略的兇手就是 SELinux。關閉 SELinux 或者臨時放行測試setenforce 0這條命令會讓 SELinux 進入 permissive 模式只記錄不攔截。注意這只是排查手段不能作為長期方案。5.3 一套完整的權限排查鏈路我把自己踩過坑的排查路徑整理成一個“問題-檢查點”流程你可以照著走先確認“用戶是誰”。id看用戶屬主組和附加組。很多時候用戶明明在devteam組里但新加的組要重新登錄或執(zhí)行newgrp devteam才會在當前會話生效。再確認“文件/目錄是誰的”。ls -l看屬主、屬組getfacl看 ACL。如果屬組不對檢查目錄 SGID 是否生效或者直接chown修正。確認“掛載層”。mount看文件系統是否以ro、noexec、nosuid方式掛載。尤其常見于外接磁盤、云盤掛載點權限明明設了但每次寫操作都被read-only file system擋住。確認“安全層”。SELinux 和 AppArmor 是排在權限模型之后的強制訪問控制。ls -Z可以查看文件的 SELinux 上下文ausearch -m avc -ts recent可以查最近的拒絕日志。對初學者來說看日志是最快定位方式。如果還是 blocked檢查程序自身邏輯。比如有些服務是以低權限用戶啟動的它能不能讀某個文件取決于它啟動時那個用戶的權限而不是你當前終端的用戶權限。這個鏈路走完絕大多數“權限不足”問題都能水落石出。最后再分享一個我的個人習慣每次搭建一個需要協作的目錄我都會把權限設計、屬主屬組、ACL 規(guī)則寫進 README 或運維文檔并且用stat -c %a %U %G %n批量核對一遍關鍵目錄。權限問題是最容易出安全事故的環(huán)節(jié)靠腦子記不可靠落到文檔和腳本里才是正道。