过往回顾：
我通过open system call wormhole来到内核空间，然后在奶奶的帮助下来到sys_open站点，正式开始了打开文件的工作。有关详细信息，请参阅考勤
1
开放系统调用链
我是一个线程，出生在这个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的函数。文件似乎即将被打开。
2
权限检测
“喂，等一下！” 突然一个声音在我耳边响起，我不禁有些紧张。莫非我嘴里的肉要飞了？我转过头，工作人员所说的奶奶出现在我身后。
“叔叔，你让我做什么？” “年轻人，我是这里的保安，你现在不能去那里，你先来安检吧。”
我真的很害怕做什么，打开一个文件是多么困难！
“安全检查？” “对，这里有一扇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, the current process fsgid!= target file gid”又报错了！我越来越担心了。
“看来你也不是这个档案的所属组。”阿姨叹了口气。我刚要问，阿姨又道：“不过别着急，还有一次机会，到第三扇门来。”
抱着一丝希望，我走进了第三扇门。不出意外，机器再次报案：“ERROR，目标文件权限为640，其他用户无访问权限！” 它甚至没有打开它的权限。
3
UGO&ACL
“别灰心，还有机会！” 阿姨突然拍了拍我的膝盖。“三扇门不是都报错了吗，哪有机会？” 我大声问。
“UGO权限测试失败，但我注意到你要访问的文件有ACL，也许有机会，但我不知道。”
“什么是UGO？什么是ACL？” 面对这两个新词，我有点困惑。
“UGO是(User,Group,Other)的缩写，Linux帝国为用户、同组用户和其他用户设置了所有文件的访问权限，Read、Write、Execute三种权限的组合，并把这个权限信息和文件的归属信息记录在索引信息inode上，就是你之前收到的那种注释。帝国把这些权限管理方法叫做UGO”
我不禁明白，“ACL 呢？”
“UGO的管理方式有点简单粗暴。为了更精细化的管理，帝国高层经过协商实施了一个新的政策，就是ACL（Access Control List），也就是访问控制列表。在UGO的基础上，一些细节可以单独记录细粒度的权限信息，比如指定组外的特殊用户允许访问文件，这个信息就构成了一个访问控制列表，这个表的地址放在了inode上。 black + sign do you see? ，表示这个文件有ACL，所以你还有机会再试一次”
听了姑姑的解释，我又燃起了希望。经过一整天的辛苦工作，我不想空手而归。
阿姨再次操作机器，出现了第四扇门。我打起精神，走了过去。
这一次机器没有发出嘶嘶声，而是一声刺耳的“SUCCESS”！阿姨走了过来，“恭喜，考试通过了，我们回家吧。”
考试通过后，我仿佛经历了一次大考，心情轻松了许多，回来的时候也柔和了许多。
4
Cgroup&SELinux
回到inode_permission卧室，阿姨把测试结果交给了另一个壮汉。
“阿呼，DAC测试已经通过了，接下来就交给你了。” 原来这人叫阿虎，正想着，就过来了。
“小子，跟我来，继续做Cgroup检测”
我的心咯噔一下，还有一个考验。“Cgroup 检测是干什么用的？”，我忍不住问道。“我们是Linux Empire进程组控制管理部下属的设备部，我们来看看你是否有权限访问相应的设备，请配合我们的工作。”阿虎郑重的回答道。
“这应该是最后的考验了吧？结束了就该放过我了吧？”
命运总是和我开玩笑。看到我的问题，另一个阿姨走了过来，“如果测试通过，我们SELinux部门会有期末测试，请坚持下去~”
我失去了力气，倒在一边，“让我休息一下。”
