setUID命令只能对文件生效，对目录不生效
在使用umask命令查看系统默认权限时，会出现4位数字的权限代号，如下：
其中第一个0表示的其实就是文件的特殊权限，包括setUID,setGID,sticky BIT权限，其于文件的用户对应的关系为：
| 特殊权限名 | 对应用户 | 对应权限代号 |
| setUID | u（所有者） | 4 |
| setGID | g（所属组） | 2 |
| sticky BIT | o（其他用户） | 1 |
当没设置文件的特殊权限（包括setUID,setGID,sticky BIT权限）时，对应的四位数字的第一位则为0。
1、setUID权限的功能
- 只有可执行(x)的二进制程序才能设定setUID权限
- 命令执行者要对该程序拥有执行权限（x）
- 命令的执行者在执行该程序时会获得该程序文件的属主身份（在执行程序的过程中灵魂附体为文件的属主）
- setUID权限只在该程序的执行过程中有效，也就是说身份改变只在程序执行过程中有效
2、给文件设定setUID权限
chmod 4755 文件名
#下面的这个是个例子
chmod 4755 abc
#或者
chmod u+s abc结果如下：
可以看出赋予了setUID权限后对应原来所有者身份的rwx变成了rws，也就是s取代了x,同时系统把文件名abc以红底白字显示（提示这个文件是不安全的，有可能有安全隐患，也就是setUID权限不安全）
如果给一个没有可执行权限的文件赋予setUID权限，那么结果为：
即对应的rw-会变成rwS,这种大S权限的（setUID权限）文件是不可执行的，没什么意义，因此需给文件的属主可执行权限再赋予setUID权限才有意义。
3、获得该程序文件的属主身份的特性（危险）
在linux中用户的密码都放在/etc/shadow文件下，而且该文件的权限都是0，即只有root用户才能打开该文件，普通用户打开该文件会提示权限不足。（当然赋予了sudo权限的用户也能打开）
那既然普通用户不能访问/etc/shadow文件，那么linux中的普通用户自己怎么修改自己的密码呢？这里就涉及到系统设计好的setUID权限。如下：
对于/usr/bin/passwd命令，系统已经预先设置为了rwsr-xr-x权限
所以普通用户执行passwd命令期间，普通用户将会得到passwd命令的属主（root）的身份，因此就可以访问/etc/shadow文件，实现自身密码的修改。
4、危险的setUID
如果系统中存在默认setUID权限之外的带有setUID权限的文件，则有可能被别人植入了木马或者其他危险文件，因此在一般的日常工作中，能够不用setUID权限就能完成的工作，就尽量不要使用setUID权限。并且做好如下几个方面的工作：
- 关键目录应该严格控制写权限。比如：“/”、“/usr”等
- 用户的密码设置要严格遵守密码三原则
- 对系统中默认具有setUID权限的文件作一列表，定时检查有没有这之外的文件被设置了setUID权限
5、定时检查系统中有无系统默认之外的具有setUID权限的文件脚本
#!/bin/bash
find / -perm -4000 -o -perm -2000 > /tmp/setuid.check
#搜索系统中所有拥有setUID和setGID的文件，并保存到临时目录setuid.check中
for i in $(cat /tmp/setuid.check)
#做循环，每次循环取出临时文件中的文件名
do
grep $i /home/fz/suid.log > /dev/null
#比对这个文件名是否在模板文件中
if [ "$?" != "0" ]
#检查上一个命令的返回值，如果不为0，证明上一个命令报错
then
echo "$i isn't in listfile!" > /home/fz/suid_log_$(date +%F)
#如果文件名不在模板文件中，则输出错误信息，并把错误信息报错到日志中
fi
done
rm -rf /tmp/setuid.check
#删除临时文件首先在检查前，先把系统中自带的setUID权限的文件找出来，并将其写入/home/fz/suid.log文件中，然后再执行此脚本。