分类： BSD
2010-06-16 01:16:47
前言：作为一个 Unix 的系统管理员，在对文件进行权限分配的时候，会遇到三个比较特殊的权限概念：设
置用户ID（setuid）、设置组ID（setgid）和粘连位（sticky bit），不知道各位是如何去学习并理解这三
个特殊权限的，我到现在为止还没有完全搞清楚这三个权限的使用，经过一段时间的反复学习，现在基本了
解了 setuid 的使用方法，为防止自己遗忘，也为了方便自己的日后使用，现在将 setuid 这个权限的使用
方法记录下来，如果大家感觉我总结出来的文章能够让大家少走弯路，本人将感到无比荣幸。
×××××××××××××
setuid
×××××××××××××
在《FreeBSD 技术内幕》一书中这样说到：setuid，如果将该位应用到可执行文件上，那么执行这个文件时
使用的权限是文件用户所有者的有效用户权限，而不是执行这个文件的用户组的权限。
为搞清这句话的确切含义，我们先用一个自己编译的简单的 .c 来说明这个问题。
我们首先以普通用户的身份登录到系统中，然后打开3个终端，其中一个使用 su 命令切换到 root 身份下，
我们且称为 A 窗口；另一个为属于 wheel 组的用户，我们且称为 B 窗口；另一个不属于任何系统组的用户
，且称为 C 窗口。
在某目录下，我们建立一个测试用的 .c 文件 test.c，文件内容如下：
test.c
-------------------
# include
int main ()
{
int a;
printf("Please enter a number:\n");
scanf("%i",&a);
printf("%i\n",a);
return 0;
}
-------------------
而后编译：
cc -o test test.c
在 A 窗口中将其设置为 754 的权限，并将其用户及组更改为 root:wheel，相关命令如下：
# chmod 754 test && chown root:wheel test
检查后文件属性如下：
-rwxr-xr-- 1 root wheel 4947 6 16 13:21 test
此时我们在窗口 B 中是无法执行该文件的，因为没有权限
> ./test
./test: Permission denied.
现在，我们将其文件属性改为 4755，也就是给它设置了 setuid 权限，那么检查属性和执行文件后的结果如
下：
-rwsr-xr-x 1 root wheel 29 6 16 01:05 test
> ./test
Please enter a number
而后通过 C 窗口来检查 test 文件是以什么身份运行的：
ps aux | grep test
可以看到如下结果：
root 9930 0.0 0.0 3164 840 p3 S+ 1:31PM 0:00.00 ./test
这样就可以看到，当一个非 root 身份的用户在执行该程序时，并不是登录用户的 ID ，而是 root
这样，基本能验证 setuid 的使用方法。
一个应用实例：了解了 setuid 的作用后，我们可以将他应用到实际操作当中。
在 Unix 系统中，只有 root 用户及 operator 组的用户能够关机，通过下面的操作，我们能再次体会到
setuid 的作用。
首先检查 shutdown 文件属性：
# ls -l /sbin/shutdown
-r-sr-x--- 1 root operator 10756 5 1 2009 /sbin/shutdown
现在我们看到 shutdown 命令已经被设置为 4550 的权限了，然后我们在执行该命令：
> shutdown
/sbin/shutdown: Permission denied.
会看到提示权限不足。而后添加我当前使用的用户名到 /etc/group 文件的 operator 组中后再次执行该命令：
> shutdown
usage: shutdown [-] [-h | -p | -r | -k] [-o [-n]] time [warning-message ...]
便可以看到，我现在不 su 到 root 身份下也可以执行关机操作了。
后来我也试验了一些其他的可执行文件，从而理解并掌握了 setuid 权限的使用方法，不知道大家是否也理
解了？
×××××××××××××
setuid
×××××××××××××
未完
×××××××××××××
sticky bit
×××××××××××××
一直没有在 FreeBSD 上试成功过这个部分的内容，可能是因为我比较笨的原因吧。今天无聊跑 debian 上又试了一下，手册中的内容得到了验证，下面把这部分的内容添加上去，免得哪天又给忘了。
环境介绍：
debian:/home/luokyo/fuck$ uname -a
Linux debian 2.6.26-2-amd64 #1 SMP Tue Jan 12 22:12:20 UTC 2010 x86_64 GNU/Linux
测试用帐户：luokyo, fuck（有点‘愤’的风格）
测试用目录：/home/luokyo/fuck
测试用文件：luokyo
首先，我们使用 luokyo 帐户在自己的 home 目录下创建一个目录，名为 fuck，并为其设置sticky bit 权限：
chmod 1777 fuck
ls -l
total 20
drwxrwxrwt 2 luokyo luokyo 4096 2010-08-14 17:40 fuck
也使 fcuk 用户进入该目录，并创建一个新文件：
debian:/home/luokyo/fuck$ touch fuck
debian:/home/luokyo/fuck$ ls
fuck luokyo
然后用 luokyo 用户删除 fuck 文件
rm fuck
rm: remove write-protected regular empty file `fuck'? y
ls
luokyo
可以看到，luokyo 用户在 fuck 目录中的操作不受影响，但反之，用户 fuck 在 fuck 目录中的操作就没有那么顺利了：
rm fuck
rm: remove write-protected regular empty file `fuck'? y
ls
luokyo
touch test
ls
luokyo test
再用 fuck 用户删除 test 文件：
debian:/home/luokyo/fuck$ rm test
rm: remove write-protected regular empty file `test'? y
rm: cannot remove `test': Operation not permitted
debian:/home/luokyo/fuck$ ls
luokyo test
这个权限让我想起 FTP 中的一个常见的权限设置：某人在其服务器中共享出一个目录，仅希望自己可以删除目录的文件及文件夹，其他用户可以添加自己的文件或文件夹，但不能对其所有的东西进行修改。当然，如果是使用 FTP 的话，可以通过其他方式得到这样的权限，该权限的设置能使某用户的某目录也能拥有一样的效果，对于本地用户来说，也是一个不错的功能。
今天闲来无事，把一块闲置的120G IDE 硬盘安装在我专门整系统的电脑里，也专门试了下sticky bit，终于成功了。
