Linux学习笔记之四(用户管理续:高级权限)

上一篇文章最后说了文件的rwx权限的前提是目录的x权限,这其实也很好理解,因为我们要访问文件(当然其实是进程访问文件),需要经过目录,进程在目录中找到对应文件的inode num,然后去磁盘上对应区域去通过一些open,write函数读写文件,目录的x权限正是管理目录中存的文件信息的访问权限的(目录的r只能给出文件名而已),cd怎么理解呢?我们切换到一个目录也要找到位置,那么目录的位置就存在父目录里面。所以目录的x权限i文件rwx,子目录可以cd的前提。这还有一个例子:

展示了如果目录只有x权限,我们可以看目录里文件的ll,但是看不了目录本身的ll,因为看目录本身的ll需要r权限。


绕来绕去是不是有些晕呢,所以一般目录我们给rx是一起的,w不轻易给。而文件是r,w可以考虑考虑再给,x特别慎重地给。但是请记住一点,root用户是一个例外(当然是可以改的)

/home/lcl(lcl的家)这个目录的权限本身只有lcl可以rwx,但是root可以ll,可以cd,下面lcl不可以ll a1用户的家。

我们再来看一个场景。


因为我们/root/666的o的权限是有w的,似乎好像可以直接删掉a的样子,但是a中还有一个文件1,并且a的o的权限是没有w的,所以递归删除不掉./root/666/a/1,所以a也删不掉。我们看删b就没有问题,而且我们改一下a的权限之后就可以了。


这里例子主要还是强调删除文件和文件权限无关,和目录的写权限有关。还有,不是说有某个目录的w权限就可以删除里面的所有文件了,还会出现上面的情况,这是因为子目录没有w权限, 这有点像你回家,你有家门钥匙,可以进到家里面,但是你如果没有书房钥匙,那你还是进不去书房。

上一讲的方式叫做ugo,是一种基本的用户权限管理方式,我们不难看出缺点,分的类太少,只有ugo三个类,不灵活。那么下面来介绍更为高级的方式。

FACL

f是file的意思。acl是access control list权限控制列表。

设置权限我们需要用到一个setfacl命令,先来看一下这个命令。

我们先介绍几个下面会用到的:-m,就是修改文件现有的acl。-x是把指定用户从acl的user中删除,而-b是删除所有的acl权限。如何查看acl呢?用的是getfacl。


什么叫做基本权限,基本权限指的就是rwx。我们先举个例子:

我们来解读一下,setfacl -m 后面的u是user的意思,不是前面ugo的所有者的意思了。中间冒号隔开,后面是用户名,再一个冒号,后面是权限。后面是文件路径。然后查看一下,getfacl加文件路径。出来的这么些行呢,前面加#的是注释,和python一样。下面是一些权限信息,user:a1:rw-就表示用户a1可读可写(虽然是进程直接对文件操作,这个前面说过很多次)。

user::这种的中间省略了owner。group::是省略了注释里面的group也就是lcl组。other是指出了上面出现过的user和group之外的用户,因为有很多,所以直接表示为o::。另外呢,我们发现ll查看的和我们用acl之后是有矛盾的,后面多的那个+就代表这个文件的权限中有acl方式设置的。我们设置了a1有rw权限,但是用ll的方式一看呢?o里面还是---啊。但是我们切到a1,确实是可以ll ~lcl的。

只不过因为a1没有x权限,所以是列出了文件名,而没有其它的信息。所以说设置了acl方式以后,不要再按照ugo方式去看ll结果的权限信息了。getfacl里还有一个mask没说,mask是干嘛的呢?参考了https://blog.csdn.net/maplesky2017/article/details/78236652。mask::中间没有省略,只是它有特别含义。

可以看到默认的mask是rwx,那么我们可不可以改呢?我们试一下。


上面这两张图提醒我们一个地方,选项和参数的位置不是所有命令都可以互换。因为setfacl -m m:rw /root成功了,但是

都失败了。这提醒我们还是老实按照help里的usage格式写吧。那么我们来关注一下命令。m:rw就是把mask的权限改为rw,但是我们getafacl查看了一下,似乎没有变化啊,似乎其它用户(非所有者)和组并没有和mask与啊。

不过我们还是有发现的,就是ll显示的九个字符分别对应的应该是ownwe,mask,other的权限,后面的加是隐藏了用acl设置的用户的权限,我们用getfacl可以看到。我们实际试一下改完mask之后的权限情况。root用户没有受到影响,因为前面说过

,不过还有一种可能,就是root这个最高权限有的。暂时先不管。

我们切到lcl

似乎并没有影响lcl的x权限啊。不要急,我们再试一下。


然后就会是这样

这说明什么,说明其它用户是不包括other的,只包含除了owner以外的权限。说到owner,我们来测试一下lcl作为owner的时候mask会不会影响到它。看那个之前,我们先了解一下前面说过的一个tty,查看终端号的命令,我开了三个会话,分别是



然后我们就看/home/lcl吧。

ownwe权限没有受影响。


不过我发现有一点很烦的就是每用setfacl一次mask就会重新恢复到rwx。就像下面。

当然其实呢,我们设完mask后getfacl时就会显示真正的权限的,只不过上面我们没有发现。233。嘛,这才时学习的过程嘛。

mask搞懂了之后,如何删除一个acl中user的一个用户呢?

lcl就不在acl的user中了,它现在在other里面。下面先看一下-b的效果。

-b就是把acl列表里面只保留owner的user,group,和other,用acl加进来的都消失。

下面稍微来一道动脑筋的题。如果我用root把chmod的所有人的x权限删掉,如何可以执行chmod?

好的,你们稍微思考一下。先不要看下面的解答。其实很简单了。

那要有人很皮的,我先用chmod把setfacl的x搞掉,再用chmod自己把自己的chmod搞掉呢?其实我们还有其它办法,不过我觉得也没有必要去那么地死抠这个小知识点,就到这里了。

当然setfacl和getfacl还有其它用法 ,就不一一讲解,下面有例子,而且上面的用法会了,其它的也不难了。

如果真的不太懂用法的格式呢?可以man一下,里面都会有例子的。


这也只是复制了权限,并没有更改ugo等用户,组的信息。到这里facl也介绍完了。但是其实权限还没有结束。

我们再来体会一下root的不讲理之处,至少对于读来说,它是不讲理的,因为上面chmod -x /usr/bin/chmod 的时候还是讲理的啊。



看来root用户的读权限似乎可以为所欲为。

读出来乱码是编码方式问题。因为chmod是二进制的,是要计算机运行的,而我们看到的频幕显示一般是用utf-8编码。其实w权限对于root用户也是毫无约束的,那为什么x有约束呢?我们新建了一个2。

看到一般新建的文件不会给x权限,为什么呢?前面也说过,文件的x权限和目录的w权限都要慎重地给,那么你可以有两种理解为什么root对于x不是为所欲为的。第一种就是由于文件的x权限很危险,就连root都被限制了,还有一种就是不给x,系统不会认为它是可执行的,当然谁都没办法执行咯。

root对目录那真的是为所欲为,


不给我rwx权限?我照样可以对目录rwx。但是一般用户就不行。

高级权限

参考了https://blog.csdn.net/zs_2014/article/details/45484405。和https://blog.csdn.net/qq_35116353/article/details/56049592

12位的话,就由四个八进制数表示,以前的三位都是省略了最前面的0。


可以看到设置完之后,1后面出现了红色背景。

红色背景代表这个文件是有setuid权限的。

我们先来说一下t的作用:


看到基本的rwx权限后面多了一个t。

30是绿色背景色,42是黑字的意思。

lcl创建的文件因为有了t,a1就删除不了。那么lcl可以删除嘛?

没有任何问题。那么去掉t我们再来试一次。


应该可以看到效果了。那么下面来讲setuid位。

先来看一段命令。



root用户改密码也是为所欲为啊,不需要输入原密码,而且密码格式没有限制(也就是提示一下密码太简单啊之类的)。而普通用户只能改自己的密码,并且需要输入原来的密码,新的密码格式还要求很高,不能太简单,太简单必须重新输入。

/bin是/usr/bin的链接,这个没有什么。我们看到u对应的位置是rws。红色背景前面说过是什么意思了。这里先说明一下修改密码的机制,修改密码执行的都是/usr/bin/passwd(链接过去的也是。为了说明/bin/passwd和/usr/bin/passwd其实是连锁的,来看一下,修改/bin/passwd,/usr/bin/passwd会不会变。下图里要注意s和S(先不管s和S的意义)。

),前面说过其实是用户启动进程,进程访问文件。执行文件当然也是要通过进程的。用户启动进程的时候,进程只有对应的用户的权限(也就是进程会有一个uid,我们看到的是用户名,计算机看到的是uid),一般来说这个uid也就不会变了,但是有setuid的文件不一样,它可以重置uid为euid(真正起作用的有效的uid),然后进程就有了euid对应的权限。我们来看一个例子(ps函数就是查看进程的一个命令)。

[]是为了去掉grep这个命令的进程。

看到用户是root,那么我们在lcl改密码是看呢?(我是开了两个会话,一个改密码时候另一个可以看的)

用户也是root而不是lcl。等会再细讲setuid。那么密码是存在哪里的呢?是存在/etc/shadow里面的,密码改动的话都进程会自动把改动写入这个配置文件里。

lcl对这个文件是没有写权限的,那为什么还可以改呢?就是因为/bin/passwd文件有setuid权限。root就不说了,写是为所欲为的。

用户名冒号后面的一堆字母就是密码,不过这个密码是有加密技术的,虽然不知道是哪一种,对比一下lcl后面的,是一样的,因为我们没有改lcl的密码,而a1后面的密码是变了的。如果没有设密码,就是!!。

那么整个改密码的过程我们就了解了,也知道了为什么普通用户也可以改密码了。但是我们似乎还是对setuid这个权限不太了解,我们来仔细了解一下这个权限。我还会讲一些视频里没有讲到的。首先呢?我们先来回顾一下加上setuid权限会有什么改变呢?

会把文件所有者的x权限改为x,如果设置setgid呢?会把属组的x改为s,设置t后面会有一个t。

我们还发现了一个奇怪的现象,用八进制的方式可以加上setuid和setgid,但是却拿不下来。要想拿下来,只能用下面的方式。

setfacl还是拿flags里的前两位ss毫无办法。


这不是个例,对lcl也一样


setuid和setgid是两位大爷,必须要chmod u-s才能请下来。下面就是一个正式的例子:

现在lcl是没有权限看1的。

那么如果我们给/usr/bin/cat一个setuid呢?

就可以查看了。原因呢,上面也有解释,lcl启动的执行/bin/cat的进程的uid是lcl的,但是这个/bin/cat是有setuid这个高级权限的, 然后执行的时候进程的uid就被改为了/bin/cat所有者,也就是root,root用户对于读写文件时为所欲为的。下面还是一个例子,我创建了一个py.py文件,内容下面可以看到。


通过上面还可以得出一个结论,python py.py的执行过程是不需要py.py的执行权限的,不然没有x就算是root用户也没办法,这我们上面演示过。去掉setuid之后。lcl就执行不了python了。

可以这样子做,其实还必须有一个前提,就是lcl有/usr/bin/python的x权限,因为lcl必须得执行python才可以让setuid发挥作用,把进程的uid改为/usr/bin/python的所有者也就是root,为什么要强调所有者呢?因为虽然一般是root,但是也不一定。

上面这张图告诉我们,ll看到的权限消息有的时候是不可信的。

s和S的区别



也就是说s=S+x。并且还发现居然还有一种现象,我称之为皇帝(root)“霸权"现象。当所有人都没有x权限的时候,就连root也无法读3,为什么呢?因为root没有cat的x权限。

但是我们给other加上之后,就不一样了。你可以去看一下,居然可以执行了,这是为什么?是因为3是空文件吗?找个不是空文件的。

就连lcl都可以看了。

我在想普通用户可以像这样吗?,上面是root是所有者。


可以看到lcl还是被拒绝了。


上面是root在属组里。下面root在o里。

root依旧是霸道横行,毫不讲理,总结上面几张图,root用户的权限还应该增加一条,无论root在u,g,还是o里,我的是我的,你们的(g,o的权限)也是我的,我猜想root用户的权限可能是ugo或的结果,那么当chmod u-x之后,root也无法执行/bin/cat就是自然的咯,而在没有u-x之前,是可以看的。


从上面的图可以看到chown命令之后flags就会消失。其实也不是因为所有者变化了,后面把u从root由改回去lcl,还是一样没有flags。对root也是一样。


提权

suid上面已经讲了很多了。图片里说都是以root执行,这个问题我们上面纠正过了,不过没有举例子,来举一个例子。


root还是依旧的不要脸。


可以看到lcl改密码的时候进程的uid就是lcl,但是由于lcl没有/etc/shadow的写权限,所以失败了。我现在给lcl加了一个w权限



确实是以文件所有和uid在跑进程。但是密码最后还是修改失败了。

这个说明其实改密码没有那么简单的。不是你在/etc/shadow加个写权限就能完成的,还需要其它操作,如果想知道还有什么其它操作,可以到

https://www.bilibili.com/video/av18945696/?p=4,前10分钟。

以上内容来自https://www.bilibili.com/video/av18945696?p=12。

前10分钟就可以了。下面介绍提权的另一种方法sudo(super user do)

为什么给了一个浩克的图呢?这是一个比喻,普通用户“发怒”的时候可以行驶超级用户的权限,怎么做呢?前面我还曾经吐槽过。首先我们先来对比一下:

为什么lcl可以sudo,而a1不可以呢?看到原因是a1不在sudoers文件里面。这个文件在哪里呢?一般都会在/etc里面。确实有/etc/sudoers。我们可以简单visudo就打开。(visudo 的效果相当于vim /etc/sudoers,切到扩展命令模式:q可以退出)。

这两行的意思是 wheel组的用户可以在任何地方,以任何用户执行任何权限,但是需要输入这个用户的密码。下一行有个前面加注释#的那一行的区别是,不需要输密码。先来试一下,改为:

就真的不用输密码了。

那么也就是说,只要把用户加入wheel组里,我们就可以用sudo为所欲为了。但是怎么加入sudo呢?我们需要useradd或者usermod。

这两个命令都在sbin里只有有root权限的人才可以执行。而且/etc/sudoers和etc/group只有root才有写的权限。所以普通用户如果没有不是root的亲信(可以把wheel组的人看作是root的亲信)是不可能修改上面的配置文件的,这样我们可以理解为什么sudo的时候只需要输自己的密码而不是root的密码,因为是root的亲信嘛,root很信任它们。(当然我们甚至可以改为不用输任何密码)。我们演示一下普通用户成为root亲信的过程。


less和more

前面我们一直用cat看文件,但是其实一般用的更多的是less,more稍微简单一些,不过我觉得用vim就行了,想了解less和more的可以看,

https://www.cnblogs.com/lidabo/p/6196457.html。

猜你喜欢

转载自blog.csdn.net/qq_41740705/article/details/80854999