一個故事看懂Linux檔案許可權管理
前情回顧：
我通過open這個系統呼叫蟲洞來到了核心空間，又在老爺爺的指點下來到了sys_open的地盤，即將開始開啟檔案的工作。
詳情參見：核心地址空間大冒險：系統呼叫
open系統呼叫鏈
我是一個執行緒，出生在這個Linux帝國。
在老爺爺的指點下，通過系統呼叫表來到了這個叫sys_open的地方。這裡很簡陋，簡單比劃了幾下就直接來到了do_sys_open的地盤。
一個負責接待的美女給我簡單辦理了手續，就讓我去裡面一個do_filp_open的房間。進去之後，這個房間裡的工作人員又讓我去後面的path_openat房間。
“打開個檔案怎麼這麼麻煩，搞這麼層級處理~”，我開始有點不爽了，便隨口抱怨了一句。
“這才哪到哪，後面要辦的手續還多著呢，年輕人一點耐心都沒有”，原來我的抱怨不小心被path_openat裡的工作人員聽到了。
我有點不好意思，硬著頭皮走了過去。
“把你要開啟的檔名和需要的許可權準備好，先去左手邊的path_init視窗先做些準備工作”，工作人員低著頭說到。我
瞅了瞅旁邊的視窗，按他說的照辦。
“再去右手邊的link_path_walk視窗，找到你要訪問的檔案”，工作人員再次說到。我繼續照辦。
“好了，我辦好了，這下該給我開啟檔案了吧？”，我累得上氣不接下氣。
“你穿過這個門，去do_last房間吧，裡面有位大爺，他會接受你的請求的。
對了，把這個帶上，一會兒他們要用”，工作人員說完給了我一張紙條。
沒想到還沒辦完手續，不過這名字既然叫do_last，應該就是最後一道手續了吧。我揣起紙條，又繼續前行。
來到do_last房間，我傻眼了，這裡看起來要做的事情很多啊，沒辦法，都走到這一步了咬著牙也得堅持下去。
一頓操作猛如虎，總算來到了一個叫finish_open函式的面前，看樣子馬上就要真正開啟檔案了。
許可權檢查
“唉，等一下！”，突然一個聲音叫住了我，我不由得心頭一緊，難不成到嘴的肉要飛了？我轉過頭來，之前工作人員口中的大爺出現在我背後。
“大爺，您叫我幹什麼？”“小夥子，我是這裡的保安，你現在還不能去那兒，先過來做個安檢”
真是怕啥來啥，打開個檔案怎麼就這麼難！
“安檢？”
“對，這裡有個may_open的大門，你先進去，檢查合格了我才能讓你開啟檔案。”，大爺一邊說一邊把我往may_open的大門裡拽。
半推半就，我進入了他口中的may_open房間，環顧四周，這裡也比較簡陋，沒兩步就到了一個叫inode_permission的房間。
這裡面的氣氛一下子緊張了起來，幾個彪形大漢在此值守。
“把你要開啟的檔案的inode拿來，還有你要的訪問許可權”，門口的一個大漢大聲說到。
“訪問許可權我知道，我是要讀取許可權READ，你說的檔案inode是什麼，我...我這裡只有檔案的名字”，我感覺到自己有點緊張。
“我要你名字幹什麼，我們需要inode資訊，不然怎麼檢查你有沒有許可權，你一路走到這裡怎麼會沒有inode資訊呢？”
他的這句話倒是提醒了我，想起剛剛在path_openat房間，那邊的工作人員給了我一個紙條。我掏了出來，上面果然記錄了inode資訊，我趕緊交給了大漢。
“你跟我來，先去做常規DAC檢查”，其中一個稍微面善的老伯帶著我又來到隔壁一個叫generic_permission的房間。
這裡面有一臺很大的機器在轟隆隆運轉著，旁邊還有三個大門，老伯走到機器前一頓操作。“我已經把你要訪問的檔案inode資訊輸入進去了，你從面前那個門走過去一下”
按照老伯的指示，我穿過了第一臺安檢門，機器自動發出了提示音：“ERROR，當前程序fsuid != 目標檔案uid”聽到提示音的我嚇了一跳。
“看來這檔案不是你所屬的使用者的啊，沒關係，再走過第二扇安檢門試試”
“老伯，這機器是怎麼知道檔案是不是我所屬的使用者的呢？”我有點好奇
“檔案的歸屬使用者id是儲存在檔案索引inode裡面的，而你所在的程序的使用者id也是儲存在程序的task_struct裡面的，這臺機器自動提取這兩個資訊比較就知道了”，老伯微笑著說到。
“原來是這樣，我的task_struct裡面確實有一個uid”
老伯搖了搖頭，“不對不對，不是那個，是fsuid。也不在那裡，是在task_struct->cred裡面的，這個cred就是你的憑證，來咱們核心空間辦事兒，到處都要檢查，你可要收好了，弄丟了就麻煩了”
“那現在怎麼辦？這檔案不是我所屬使用者的，我是不是沒有許可權開啟呢？”
“彆著急，你再走過第二扇門試試”
聽從老伯的指示，我又穿過了第二道門，機器又一次發出了提示音：“ERROR，當前程序fsgid != 目標檔案gid”
又報錯了！我越發的擔心起來。
“看來你也不在這個檔案的歸屬組裡啊”，老伯嘆了口氣。我正想問，老伯又開口了，“不過彆著急，還有一次機會，快走進第三扇門”
抱著一絲希望，走進了第三扇門，沒有意外的機器又報警了：“ERROR，目標檔案許可權640，其他使用者無訪問許可權！”
我的心情跌落到了谷底，沒想到忙活了這麼久，居然沒有許可權開啟。
UGO & ACL
“先彆氣餒，還有機會！”，老伯突然拍了下我的肩膀。
“不是三道門都報錯了嗎，怎麼還有機會呢？”，我小聲的問道。
“UGO許可權檢查沒通過，不過我注意到你要訪問的檔案有ACL，興許還有機會也未可知。”
“UGO是什麼？ACL又是什麼”，面對這兩個新詞，我一下有點懵。
“UGO就是(User, Group, Other)的縮寫，Linux帝國為所有檔案針對所屬使用者、同組使用者和其他使用者分別設定了訪問許可權，Read、Write、Execute三種許可權的組合，並把這些許可權資訊和檔案的歸屬資訊記錄在了索引資訊inode裡面，就是你之前拿到的那個紙條，帝國把這種許可權管理方式叫UGO”
我聽得似懂非懂，“那ACL又是什麼呢？”
“UGO的管理方式有些簡單粗暴，為了更精細化的管理，帝國高層經過商議後，頒佈了新的政策就是ACL(Access Control List)，訪問控制列表的意思，在UGO的基礎上，可以單獨記錄一些細粒度的許可權資訊，比如指定組外某一個特殊使用者允許對檔案的訪問，這些資訊就構成了一個訪問控制列表，把這個表的地址放到了inode裡面，你看到那個紅色的＋號沒，表示這個檔案是有ACL的，所以你還有機會再試一試”
聽完老伯的講解，我又重新燃起了希望，辛苦大半天，我可不想空手而歸。
老伯再次對著機器一頓操作，出現了第四扇門，我給自己鼓了鼓勁，走了過去。
這一次機器沒有發出刺耳的聲音，而是一聲清脆的“SUCCESS”！
老伯走了過來，“恭喜，檢查通過了，咱們回去吧”
檢查通過的我彷彿經歷了一場大考，心裡如釋重負，回去的步伐輕快了許多。
Cgroup & SELinux
回到inode_permission房間，老伯向另一個彪形大漢提交了檢查結果。
“阿虎，DAC檢查已經通過了，下面交給你了。”原來這一位叫阿虎，正想著，他走了過來。
“小子，跟我來吧，繼續做Cgroup檢查”
我的心咯噔一下，居然還有檢查。“Cgroup檢查又是幹嘛的？”，我忍不住問到。
“我們是Linux帝國程序分組控制管理部下轄的devices部門，在此奉命檢查你是否有許可權訪問對應的裝置，請配合我們的工作”，阿虎嚴肅正經的回答。
“這應該是最後一次檢查了吧，完事兒總該放我走了吧？”
命運總是會跟我開玩笑，聽到我的問題，旁邊又一位大哥走了過來，“等會檢查通過的話，我們SELinux部門還有最後一道檢查，麻煩您再堅持一下~”
我一下沒了力氣，癱坐了一旁，“容我休息休息”。
未完待續·······
彩蛋
在我休息的間隙，隔壁generic_permission房間又傳來了幾下錯誤的提示音，不知道哪個倒黴蛋要空手而歸了。
一會兒老伯就出來了，“阿虎，DAC檢查已經通過了，下面交給你了。”
“老伯，我剛剛明明聽到了機器報警，檢查不通過才對啊”，我走上去問老伯。
“哦，你說他啊，他是一個特權程序的執行緒，有CAP_DAC_OVERRIDE能力標記，可以無視那臺機器，哈哈”
欲知後事如何，請關注後續精彩......
往期熱門文章：
誰動了你的HTTPS流量？
堆疊裡的祕密行動：劫持執行流
堆疊裡的悄悄話——智慧指標
路由器裡的廣告祕密
核心地址空間大冒險2：中斷與異常
一個DNS資料包的驚險之旅
DDoS攻擊：無限戰爭一條
SQL注入引出的驚天大案
核心地址空間大冒險：系統呼叫
一個HTTP資料包的奇幻之旅
遠去的傳說：安全軟體群雄混戰史
預設瀏覽器爭霸傳奇
我是一個流氓軟體執行緒
我是一個防毒軟體執行緒