一个故事看懂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数据包的奇幻之旅

远去的传说:安全软件群雄混战史

默认浏览器争霸传奇

我是一个流氓软件线程

我是一个杀毒软件线程

posted @ 2020-02-25 14:10  轩辕之风  阅读(1780)  评论(10编辑  收藏