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