一个故事看懂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能力标记，可以无视那台机器，哈哈”

欲知后事如何，请关注后续精彩......

往期热门文章：