UGO、ACL、SUID、SGID 都是什么

UGO

文件的所有者和组,Linux权限控制最基本的方式。ugo指 user、group 和 other 三个单词的首字母组合 。

user

文件的所有者,一般是创建该文件的用户,对该文件具有完全的权限。在一台允许多个用户访问的 Linux 主机上,可以通过文件的所有者来区分一个文件属于某个用户。当然,一个用户也无权查看或更改其它用户的文件。

group

文件所属的组。加入系统是分给了多个用户使用的,如果每个用户只能查看和修改自己创建的文件就太不方便了。group就是一种机制:把需要合作的用户都添加同一个组中,在设置文件的访问权限时,允许这个组中的用户对该文件进行读取、修改和执行。

other

如果我想把一个文件共享给系统中的所有用户该怎么办?通过组的方式显然是不合适的,因为需要把系统中的所有用户都添加到一个组中。并且系统中添加了新用户该怎么办?这个问题可以通过other权限赋值来解决。在设置文件的访问权限时,设置other用户对该文件进行读取和修改的权限。

ugo预览

在Linux下,使用命令ls -l显示文件详细信息,包括文件的ugo权限。

$ ls -l
-rw-r--r-- 1 test01 deepin 11 7月  25 21:28 test001

最前面的’-’,表示文件为普通类型
第一组的 ‘ rw- ‘ ,表示文件属主对文件具有读和写权限,但没有执行权限 。
第二组的 ‘ r– ‘ ,表示同组其他用户对文件具有读权限,但没有写入和执行权限。
第三组的 ‘ r– ‘ ,表示其他组用户对文件具有读权限,但没有写入和执行权限。

解释一下读写执行的权限。

r (read):可以读取文件的实际内容,比如读取文本文件内的文字等。
w (write):可以编辑、增加、删除文件的内容(但不含删除该文件)。
x (execute):该文件具有可以被系统执行的权限。

以数字表示权限的方式如下:
r: 4
w: 2
x: 1
同理,使用ls -l 同样可以显示目录的ugo权限。创建了一个目录test,使用ls -l查看目录的ugo权限:

$ ls -l
drwxr-xr-x 2 test01 deepin 4096 7月  25 21:37 test

最前面的 ‘ -d ‘,表示是目录。
r : 可以查看目录中内容,
w : 可以增删目录中内容,
x : 可以进入目录,

会发现默认创建目录的权限是755 ,而文件的默认权限是644。这是因为系统的默认权限掩码umask是0022,用户可以使用命令umask查看和修改系统默认的umask值。文件和目录的默认权限计算公式为 :7777 – umask 。

$ umask   #查看系统的默认umask 
0022
$ umask -S 0002 #设置系统的默认umask为0002

ACL

ACL概念

ACL(Access Control List),访问控制列表。ACL可以针对单一用户、单一文件或目录来进行r、w、x的权限设置, 即指定特定的用户对特定的文件拥有的特殊权力。

举个栗子:
假如有deepin用户在家目录创建了一个工作目录workdir,该工作目录的ower是deepin:deepin。该工作目录里面的创建的所有文件就自动属于deepin组。由于是工作目录,我只想开放给划在deepin组中的账户开放可读权限,并不想给other任何权限,那么该目录的UGO权限如下:

drwxr-x---   2 deepin deepin     4096 8月  21 19:24 workdir

现在如果有另外一个账户test,而该账户并不属于deepin组,那么如果由于工作需要,想把授予test用户对该目录的查看,那么就可以 使用ACL进行做了。
首先查看文件系统是否支持ACL权限,默认挂载都是支持ACL的。

$df -h
/dev/sda7        33G   30G  1.2G   97% /


$ sudo tune2fs -l /dev/sda7 |grep acl
Default mount options:    user_xattr acl      #默认挂载参数中有ACL


$ dpkg -l acl libacl1-dev |tail -n 2
ii  acl            2.2.52-3+b1  amd64        Access control list utilities
ii  libacl1-dev    2.2.52-3+b1  amd64        Access control list static libraries and headers       
#看到acl和libacl1-dev已经默认安装。

查看workdir的ACL权限,只有UGO的相关权限。

$ sudo getfacl workdir/
# file: workdir/
# owner: deepin
# group: deepin
user::rwx
group::r-x
other::---

设置test用户对目录的可读和可进入权限:

$sudo setfacl -m u:test:rx workdir/
$sudo getfacl workdir/
# file: workdir/
# owner: deepin
# group: deepin
user::rwx
user:test:r-x         #看到用户test已经有了r和x的权限。
group::r-x
mask::r-x
other::---

切换到test用户,访问该目录,访问正常。

$ su test
密码:
test@deepin-PC:/home/deepin$ cd workdir/
test@deepin-PC:/home/deepin/workdir$ pwd
/home/deepin/workdir

设置过ACL权限的文件或者目录,使用ls 命令查看时,文件权限属性后面多了+标志。

SUID、SGID

SUID 是 Set User ID, SGID 是 Set Group ID的意思。如果一个文件被设置了SUID或SGID位,会分别表现在所有者或同组用户的权限的可执行位上。当s这个标志出现在文件所有者的x权限上时,此时就被称为Set UID。suid意味着如果A用户对属于他自己的shell脚本文件设置了这种权限,那么其他用户在执行这个脚本的时候就拥有了A用户的权限。当s出现在文件的所属用户组x权限位置上时,就是SGID,和SUID一样,只是SGID是获得该程序所属用户组的权限。

如果root用户对某一脚本设置了这一权限的话则其他用户执行该脚本的时候则拥有了root用户权限。同理,guid意味着执行相应脚本的用户则拥有了该文件所属用户组中用户的权限。

举个例子:一般账户想在/root目录下创建是没有权限的。通过给二进制程序/usr/bin/mkdir增加UID权限,则可以实现不用sudo就可以在/root目录操作。演示如下:

deepin@deepin-PC:~/testuid$ mkdir /root/test1
mkdir: 无法创建目录"/root/test1": 权限不够                             #没有权限,操作失败。

deepin@deepin-PC:~/testuid$ sudo chmod u+s /usr/bin/mkdir   #设置mkdir的UID属性。

deepin@deepin-PC:~/testuid$ mkdir /root/test1                          
deepin@deepin-PC:~/testuid$ echo $?                        
0                                                                                             #操作成功。

deepin@deepin-PC:~/testuid$ ls -la /usr/bin/mkdir 
-rwsr-xr-x. 1 root root 81032 4月  25 15:46 /usr/bin/mkdir      #看到mkdir属性为有s标志。

这个SUID只能运行在二进制的程序上(系统中的一些命令),不能用在脚本上,同样也不能放到目录上,放上也是无效的。理解了SUID,SGID也很容易理解。SUID有如下的限制和功能:

  1. SUID权限仅对二进制程序有效;
  2. 执行者对于该程序需要具有x的可执行权限;
  3. 本权限仅在执行该程序的过程中有效;
  4. 执行者将具有该程序所有者的权限。

所以系统中可执行文件一般不应该被设置SUID属性,而常见的情况是在一些主机被入侵之后,一些病毒文件通常具有SUD属性。在服务器测试中,需要全盘扫描一下,排除异常的具有SUID属性的可执行文件。执行命令 “sudo find / -perm -04000 -type f -ls” 可以把根分区中具有SUID属性的文件全部找出来。

发表评论

电子邮件地址不会被公开。 必填项已用*标注