标签:软链接硬链接特殊权限
6月7日任务2.18 特殊权限set_uid
2.19 特殊权限set_gid
2.20 特殊权限stick_bit
2.21 软链接文件
2.22 硬连接文件
2.18 特殊权限 set_uid 普通用户临时拥有所有者的身份 u.在系统中已经有设置,可以参看passwd命令。
红色
前面rws s就是set_uid 权限
即使是root在密码文件里也是没有任何权限,但是root是超级管理员所以可以有。但是普通用户如何改自己的密码呢?这样就需要一个权限,set_uid可以让普通用户在执行passwd时候就会临时拥有root的身份,这样就可以临时去改密码。前提是二进制文件比如ls cat
可以让普通用户在执行带红色权限的那些命令的瞬间被赋予该命令的所有者的权限。
如何给一个文件授权set_uid权限?
比如一个用户没有查看root文件夹的权限,也就是ls命令权限不够
这个时候就需要临时给他加一个可以查看root的权限
chmod u+s /usr/bin/ls
改完ls的权限之后,就可以看root目录了
想去掉这个权限也很简单
chmod u-s /usr/bin/ls
也可以通过这种模式来写
chmod u = rws 但是这种因为没有x权限所以显示的是S 加上x权限 chmod u+x 即可以正常显示 s
目录能不能加set_uid权限呢?
可以,但是意义不大
特殊权限 set_gid 普通用户临时获得所有组的权限
作用在组权限位上,相对于set_uid区别是uid是作用于用户。做个实验,把g 加上s 看看颜色变成了什么,同时s在组里
因为本身这个目录给本组的权限就是可以读可以进入 所以一旦给g赋予了s的权限,其他用户就临时获得了同组的权限
试着把s权限去掉,就马上看不到了
正常情况下,root创建的目录以及文件所属组都是root 但是当使用g+s的时候 set_gid 在目录下面创建子文件,子目录的时候,所属组会跟着父级目录保持一致
set_gid 不仅可以作用文件也可以作用目录,当作用在文件上的时候跟set_uid的作用是一样的,可以让普通用户临时拥有所属组的身份。
作用在目录上的时候,创建子目录和子文件的所属组和该目录的所属组保持一致。
特殊权限 stick_bit 防止别人删除自己的文件 root除外
注意它的权限是rwt 防删除位
tmp是一个哪个用户都可以去访问的目录,但是谁的文件谁做主。权限是靠父级目录决定的
“要删除一个文件,你不一定要有这个文件的写权限,但你一定要有这个文件的上级目录的写权限。也就是说,你即使没有一个文件的写权限,但你有这个文件的上级目录的写权限,你也可以把这个文件给删除,而如果没有一个目录的写权限,也就不能在这个目录下创建文件。”
举个例子:
bill用户创建的文件,其他用户可以访问修改但是无法删除
软链接文件
所谓软链接就是存储路径。路径越长,文件越大。软链接可以节省空间,省去了拷贝。
如何做软链接?
ln -s 源文件 软链接文件
不仅仅是可以软链接文件, 也可以软链接目录。
尽量使用据对路径,下面的红色说明不存在,原因就是使用了相对路径。使用了绝对路径之后就没有问题了。
实际工作场景的例子:
df -h 查看磁盘分区
假设其中的一个磁盘的内存即将使用完毕,同时还有进程在不停的写入数据,可能会导致磁盘满导致问题。
解决办法:
把写的文件放到另外的有足够空间的分区下面。但是前提是不能弄这个文件的路径。
假设 boot下有一个文件bill.log已经很大了但是还在写,怎么操作?
1, 首先把/boot/bill.log拷贝到另一个目录 cp /boot/bill.log /bill.log
2. 删掉原来的log文件 rm /boot/bill.log
3. 做软链接 ln -s /bill.log /boot/bill.log
就是说将软链接替换了文件,文件放到其他位置,用软链接继续工作,但是内容都到了其他位置。
硬链接文件
inode ls -i 显示inode号码
这一列表示了多少个文件使用了相同的inode号
硬链接:
创建了一个文件,另一个文件和它的inode号一样,这俩个相互为硬链接。
软链接不能删除,一旦删除就会出现无法链接的情况。但是硬链接不受影响。因为互为硬链接而且互相都是实打实的存在,删除一个后,同一个inode号的文件少了一个而已。或者这样理解,inode才是真正存数据的地方,其他的指向inode都是皮。删掉一个硬链接也只是少了个皮,指向该inode的文件少了一个而已。
硬链接再多也不会多站空间,因为inode本身占据空间。所以多少个硬链接都没有影响存储空间。
不能对目录做硬链接。硬链接只能对文件做,但是不能跨分区。
26期20180607 set_uid stick_bit 软硬连接
标签:软链接硬链接特殊权限
原文地址:http://blog.51cto.com/13691454/2126132