cap_fsetid能力分析

• cap_fsetid: 确保在文件被修改后不修改setuid/setgid位

简单来说就是：当进程/可执行文件拥有cap_fsetid能力时，当用户对文件F（含有setuid/setgid位）执行写操作后，该文件的setuid/setgid位不会发生变化。

首先我们先了解下什么是setuid/setgid位

SUID是什么？

1. 我们先看一下不带setuid位的文件权限

$ touch /tmp/ddd
$ ls -l /tmp/ddd
-rw-r--r-- 1 root root 0 Nov  4 14:29 /tmp/ddd

• -rw-r--r--中的第一位-表示/tmp/ddd类型为文件
• -rw-r--r--中的第2-4位rw-表示/tmp/ddd文件属主拥有的权限为: 读写
• -rw-r--r--中的第5-7位r--表示/tmp/ddd文件所属用户组（root）下其他用户对其拥有的权限为: 读
• -rw-r--r--中的第5-7位r--表示其他用户组（非root）下用户对其拥有的权限为: 读
• 第一个root表示该文件属主为root

• 第二个root表示该文件所属用户组为root

• 当我们对其追加suid/时：

$ chmod u+s /tmp/ddd
$ ls -l /tmp/ddd
-rwSr--r-- 1 root root 0 Nov  4 14:49 /tmp/ddd

当我们再追加+x可执行权限时，S变为了s

$ chmod u+x /tmp/ddd
$ ls -l /tmp/ddd
-rwsr--r-- 1 root root 0 Nov  4 14:49 /tmp/ddd

setuid的使用场景为：对归属root的程序/可执行文件（二进制）进行setuid，普通用户运行该程序时，是以程序所属的用户的身份(root)运行。

SGID是什么？

SGID和SUID的不同之处就在于，SUID赋予用户的是文件所有者的权限，而SGID赋予用户的是文件所属组的权限。

对比一下：

• 设置SUID的文件权限

$ ls -l /tmp/ddd
-rwsr--r-- 1 root root 0 Nov  4 14:49 /tmp/ddd

• 设置SGID的文件权限

$ ls -l /tmp/ddd
-rw-r-sr-- 1 root root 0 Nov  4 14:53 /tmp/ddd

cap_fsetid应用样例

那么让我们基于CentOS7，透过下面两个例子来理解cap_fsetid的功能：

测试不设置cap_fsetid情况下对含有SUID/SGID位的文件进行修改

1. 创建用户test，用于测试

$ adduser test

1. 使用root身份创建一个文件

$ touch /tmp/123
$ chmod 6777 /tmp/123
$ ls -l /tmp/123
-rwsrwsrwx 1 root root 0 Nov  4 15:02 /tmp/123

1. 切换至test用户对/tmp/123编辑写入

$ su - test
$ vim /tmp/123
$ ls -l /tmp/123
-rwxrwxrwx 1 root root 5 Nov  4 15:03 /tmp/123

此时我们发现，在对/tmp/123写入后，文件权限已然发生变化。（无SUID/SGID）

清理测试用例

$ rm -f /tmp/123
$ userdel -r test

测试设置cap_fsetid情况下对含有SUID/SGID位的文件进行修改

1. 创建用户test，用于测试

$ adduser test

1. 使用root身份创建一个文件

$ touch /tmp/123
$ chmod 6777 /tmp/123
$ ls -l /tmp/123
-rwsrwsrwx 1 root root 0 Nov  4 15:02 /tmp/123

1. 对vim添加cap_fsetid的功能

$ setcap cap_fsetid=eip /usr/bin/vim

1. 切换至test用户对/tmp/123编辑写入

$ su - test
$ vim /tmp/123
$ ls -l /tmp/123
-rwsrwsrwx 1 root root 24 Nov  4 15:07 /tmp/123

此时我们发现，在对/tmp/123写入后，文件权限并未发生变化。

清理测试用例

$ userdel -r test
$ setcap -r /usr/bin/vim