当前位置: 首页 > news >正文

Linux 文件的特殊权限—Sticky Bit(SBIT)权限

本文为Ubuntu Linux操作系统- 第十九期~~
其他特殊权限: 【SUID 权限】和【SGID 权限】
更多Linux 相关内容请点击👉【Linux专栏】~
主页:【练小杰的CSDN】

在这里插入图片描述

文章目录

  • Sticky(SBIT)权限基本概念
  • Sticky Bit 的表示方式
    • 举例
  • 设置和取消 SBIT 权限
    • 设置 SBIT 权限
    • 取消 SBIT 权限
  • 有关 SBIT 权限的实例
    • 运用场景
    • 第一步:在`/`目录下创建一个目录`share_dir`做为测试
    • 第二步:设置`share_dir`的`Sticky`位
  • ⚠️ SBIT 权限注意事项
  • 特殊权限SUID,SGID,SBIT归纳
    • 数字设置规则总结
    • 举例
  • 综合案例
    • 建立组project和用户userA,userB
    • 建立公用的工作目录为`/user/com_project`并设置权限为:`drwx rwx — root project`
    • 在目录`/user/com_project`下分别以userA和userB的身份创建两个空文件fileA和fileB
    • 再将`SGID`权限设置到目录/user/com_project中并观察结果
    • ⚠️注意

在这里插入图片描述

Sticky(SBIT)权限基本概念

  • SBIT只对目录有效,对文件却是无效的,它的作用就是防止别人删除对方的资料。

  • 当用户在该目录下创建新文件或目录时,只有以下的用户可以删除或重命名该目录中的文件:

    • 文件的所有者
    • 目录的所有者
    • 超级用户(root)

ContOS Linux系统中,最具有代表性的就是/tmp目录。任何人都可以在/tmp内增加、修改文件(“drwxrwxrwt. 25 root root 4096 Jul 1 06:58 tmp”),但仅有该文件/目录建立者与 root能够删除自己的目录或文件。

Sticky Bit 的表示方式

  • Sticky Bit 通常用字母 tT 表示:

小写 t:表示目录的其他人(other)执行权限位被设置,并且 Sticky Bit 被设置。
大写 T:表示目录的其他人执行权限位未被设置,但 Sticky Bit 被设置。

举例

 drwxrwxrwt  # t 表示 Sticky Bit 被设置。drwxrwxrwT#T 表示 Sticky Bit 被设置,但其他人没有执行权限。

设置和取消 SBIT 权限

  • 使用 chmod 命令的符号模式 或八进制模式来设置和取消 Sticky Bit 权限

设置 SBIT 权限

  • 字符设置法
chmod +t 目录名
  • 八进制设置模式
    Sticky Bit 对应的八进制值是 1,通常放在权限的最前面
chmod 1777 目录名

上面的 1 表示 Sticky Bit,777 是目录的常规权限。

取消 SBIT 权限

  • 字符模式
chmod -t 目录名
  • 八进制模式
chmod 0777 目录名

有关 SBIT 权限的实例

运用场景

共享目录里,只能删除自己创建或上传的文件,除了root其他人不能删除。

第一步:在/目录下创建一个目录share_dir做为测试

share_dir设置777权限。创建文件file_a,将file_a的所属用户以及所属组都改成myuser1
然后进入myuser2用户,测试是否可以删除file_a文件

  • 创建目录share_dir并设置777权限
[root@openstack01 /]# mkdir share_dir
[root@openstack01 /]# chmod 777 share_dir
  • 创建文件file_a并把该文件的所属用户以及所属组都改成myuser1
[root@openstack01 /]# touch file_a
[root@openstack01 /]#chown myuser1:myuser1 file_a 
  • 切换普通用户myuser2,并尝试删除file_a文件
[root@openstack01 share_dir]# su myuser2
[myuser2@openstack01 share_dir]$ rm –r f file_a

这时,我们发现,用户myuser2可以删除在公共目录share_dir里其他用户的文件!!这是有很大安全隐患的,不应该让其他用户删除你的文件!!

第二步:设置share_dirSticky

创建文件file_b,将file_b的所属用户以及所属组都改成myuser1
然后进入myuser2用户,测试是否可以删除file_b

  • 设置目录share_dir的SBIT权限
[root@openstack01 /]# chmod o+t share_dir | ll
drwxrwxrwt.   2 root root    20 Jun  5 22:13 share_dir
  • 创建文件file_b,并将该文件的所属用户以及所属组都改成myuser1
[root@openstack01 share_dir]# touch file_b
[root@openstack01 /]#chown myuser1:myuser1 file_b
  • 切换普通用户myuser2,并尝试删除file_b文件
[root@openstack01 share_dir]# su myuser2
[myuser2@openstack01 share_dir]$ rm -rf file_b
rm: cannot remove ‘file_b’: Operation not permitted

可以看到,设置共享目录share_dir的SBIT权限后,只能删除自己创建或上传的文件,除了root其他人不能删除

⚠️ SBIT 权限注意事项

  • 安全性:
    虽然 Sticky Bit 可以防止文件被删除,但它不防止文件被读取或修改。要进一步保护文件,需要设置适当的文件权限。

  • 兼容性:
    大多数现代Linux系统都支持 Sticky Bit,但在某些特殊环境下可能需要额外配置。

特殊权限SUID,SGID,SBIT归纳

数字设置规则总结

与设置文件或目录的rwx的数字法规则421类似,suid,sgid,sbit的数字设置法也是421规则:
SUID->4
SGID->2
SBIT->1

举例

假设一个文件的基本权限是“-rwxr-xr-x”,若将其权限修改为“-rwsr-xr-x”,因为s在用户权限中,就是要设置这个文件的SUID,所以原先的基本权限755前面还要加上4,也就是4755

  • 执行以下命令:
chmod 4755 filename

若是想把该文件既要设置SUID又要设置SGID,则两个权限相加变成4+2=6

  • 使用以下命令就可以了
chmod 6755 filename
-rwSrwSrwT 1 root root  0 Feb  6 21:49 filename

可以发现,还有可能会出现大写S大写T的情况。
这是因为st是替代x这个权限的,但是,如果它本身没有x这个权限,修改为s或t时就会变成大写的S或大写的T。

综合案例

  • 实现需求:进行项目开发时,往往需要多人合作在同一环境下进行工作,要求能互相访问和编辑彼此的文件,那么项目组所有成员就构成一个组(group)

下面我们以项目组成员由A与B两个用户组成的情况说明:
假设系统管理员将他们放到project组,同时给他们分配了一个公用的工作目录为/user/com_project,并设置该工作目录的权限为 : drwx rwx — root project
说句话来说,就是除了root用户和project组内用户,其它用户是不能访问这个目录的

建立组project和用户userA,userB

[root@localhost /]# groupadd project
[root@localhost /]# useradd -G project userA
[root@localhost /]# useradd -G project userB
[root@localhost /]# id userA
uid=1003(userA) gid=1004(userA) groups=1004(userA),1003(project)
[root@localhost /]# id userB
uid=1004(userB) gid=1005(userB) groups=1005(userB),1003(project

建立公用的工作目录为/user/com_project并设置权限为:drwx rwx — root project

[root@localhost /]# mkdir -p user/com_project
drwxr-xr-x. 2 root root 6 Jul  2 20:13 com_project
[root@localhost user]# chgrp project com_project
[root@localhost user]# chmod 770 com_project | ls -l
drwxrwx---. 2 root project 6 Jul  2 20:13 com_project

可以看到,修改后的com_project权限为drwxrwx---

在目录/user/com_project下分别以userA和userB的身份创建两个空文件fileA和fileB

[root@localhost user]# su userA
[userA@localhost user]$ cd com_project
[userA@localhost com_project]$ touch fileA
[userA@localhost com_project]$ exit
[root@localhost user]# su userB
[userB@localhost user]$ cd com_project
[userB@localhost com_project]$ touch fileB
[userB@localhost com_project]$ exit 

分别查看文件fileA和fileB的基本权限

-rw-rw-r--. 1 root userA 0 Dec 27 20:31 fileA
-rw-rw-r--. 1 root userB 0 Dec 27 20:32 fileB
  • 从上面可以发现,用户userA和userB虽然在同一组里,但他们创建的文件所属的组并不是project,文件fileA所属组为userA,而fileB所属组为userB。
  • 这样,userA和userB相对于对方还是属其它用户(other),并没有因为是同一个项目组而改变文件间的操作权限!!
  • 同时,两个文件的权限与所在的目录/user/com_project也没什么联系,实现不了同一个项目组对同组文件的权限设置的初衷。
  • 所以单纯使用基本权限rwx对于项目的管理还是不够的。

再将SGID权限设置到目录/user/com_project中并观察结果

[root@localhost /]# chmod g+s /user/com_project
drwxrws---. 2 root project 32 Dec 27 21:32 com_project
  • 目录/user/com_project下分别以userA和userB的身份各自创建一个空文件fileA、fileB以及一个目录dirA和dirB,比较设置SGID后的基本权限有什么不同
[root@localhost com_project]# su userA
[userA@localhost com_project]$ touch fileA
[userA@localhost com_project]$ mkdir dirA
[userA@localhost com_project]$ exit
[root@localhost com_project]# su userB
[userB@localhost com_project]$ touch fileB
[userB@localhost com_project]$ mkdir dirB
[userB@localhost com_project]$ exit
  • 比较设置完目录/user/com_project的SGID前后创建的文件权限

目录dirA和dirB的权限

drwxrwsr-x. 2 userA project 6 Dec 27  22:13 dirA
drwxrwsr-x. 2 userB project 6 Dec 27  22:14 dirB

文件fileA、fileB的权限比较

#fileA设置SGID权限前
-rw-rw-r--. 1 root  userA   0 Dec 27  20:31 fileA
#fileA设置权限之后
-rw-rw-r--. 1 root  project 0 Dec 27  22:13 fileA
#fileB设置SGID权限前
-rw-rw-r--. 1 root  userB   0 Dec 27  20:32 fileB
#fileB设置权限之后
-rw-rw-r--. 1 root  project 0 Dec 27  22:14 fileB

这时,我们可以看到当目录/user/com_project拥有SGID权限后,在这个目录下建立的文件所属的组都会强制变为project。 而且,所创建的子目录会继承它的SGID权限。
同一项目组的成员就能够互相访问和编辑彼此的文件了,从而达到协同工作的目的!!!

⚠️注意

  • 这时目录/user/com_project的基本权限为:drwxrws---
  • 除了root用户和project组成员外,其它用户是无法访问目录/user/com_project下的文件的!!

至此,Linux系统的三种特殊文件权限已经讲完了😆
如果还想了解更多,查看主页【练小杰的CSDN】!!!
2024年还有4天就结束了,下周再见,各位🧍‍♂️大佬们~~

http://www.lryc.cn/news/510744.html

相关文章:

  • MIPI D-PHY/C-PHY/M-PHY 高速串行接口标准
  • USB免驱IC读写器QT小程序开发
  • OSCP靶场训练冒险之kioprix4:shell逃逸以及利用数据库提权
  • NIPS2014 | GAN: 生成对抗网络
  • Postman接口测试01|接口测试基础概念、http协议、RESTful风格、接口文档
  • Linux系统编程——详解页表
  • SpringBoot + HttpSession 自定义生成sessionId
  • 循环对称复高斯分布(Circularly Symmetric Complex Gaussian Distribution)
  • xinput1_3.dll放在哪里?当xinput1_3.dll丢失时的应对策略:详细解决方法汇总
  • 基于STM32的智能家居环境监控系统设计
  • Vscode + gdbserver远程调试开发板指南:
  • 大表:适用于结构化数据的分布式存储系统
  • 深入解析MVCC中Undo Log版本底层存储读取逻辑
  • 游戏引擎学习第64天
  • Effective C++ 条款33:避免遮掩继承而来的名称
  • UEFI Spec 学习笔记---4 - EFI System Table(1)
  • 【微信小程序】3|首页搜索框 | 我的咖啡店-综合实训
  • 独一无二,万字详谈——Linux之文件管理
  • React:前端开发领域的璀璨之星
  • C/C++ 数据结构与算法【哈夫曼树】 哈夫曼树详细解析【日常学习,考研必备】带图+详细代码
  • 基于NodeMCU的物联网窗帘控制系统设计
  • 喜报 | 擎创科技入围上海市优秀信创解决方案
  • windows10下使用沙盒多开uiautoanimation可行性验证
  • 电脑报错wsdprintproxy.dll丢失?修复wsdprintproxy.dll文件缺失的实用方法
  • Kubernetes 的资源管理方式
  • layui动态拼接生成下拉框验证必填项失效问题
  • VUE3+VITE简单的跨域代理配置
  • Xdebug
  • IDEA | SpringBoot 项目中使用 Apifox 上传接口
  • 列表分页返回对象