在Linux系统中每个普通用户都可以更改自己的密码，这是合理的设置。
问题是：用户的信息保存在文件/etc/passwd中，用户的密码保存在文件/etc/shadow中，也就是说用户更改自己密码时是修改了/etc/shadow文件中的加密密码，但是，
/etc/passwd文件每个用户都有读权限但是只有root有写权限，/etc/shadow文件只有超级用户root有读写权限，也就是说普通用户对这两个文件都没有写权限无法写入新密码，为什么普通用户可以更改密码呢？
PS：在Linux中设置或更改用户密码，是先写入到/etc/passwd文件然后通过pwconv命令转换到/etc/shadow文件，执行pwunconv命令可观察到转换前效果，会观察到/etc/shadow文件神奇的消失掉了，而/etc/passwd文件中原来打x的地方变成了真正的加密密码。
其实，用户能更改密码真正的秘密不在于文件的权限，而在于更改密码的命令passwd 。
passwd命令有一个特殊的权限标记s ，存在于文件所有者的权限位上。这是一类特殊的权限SetUID ，可以这样来理解它：当一个具有执行权限的文件设置SetUID权限后，用户执行这个文件时将以文件所有者的身份执行。passwd命令具有SetUID权限，所有者为root（Linux中的命令默认所有者都是root），也就是说当普通用户使用passwd更改自己密码的时候，那一瞬间突然灵魂附体了，实际在以passwd命令所有者root的身份在执行，root当然可以将密码写入/etc/shadow文件（不要忘记root这个家伙是superuser什么事都可以干），命令执行完成后该身份也随之消失。
可以试验用root身份修改passwd命令权限去掉SetUID ：
再尝试以普通用户身份登录后修改密码，就会发现提示：
普通用户无法修改密码，所以只要能够想明白为什么普通用户可以更改密码就可以大概了解SetUID权限的作用。
接下来我们用两个SetUID的按理来进一步诠释下它的概念——
案例一：SetUID授权示例
为便于深入理解SetUID ，笔者以touch命令为例做一演示。
普通用户samlee用touch创建文件newfile01 ：
文件的创建者默认就是所有者，所以文件newfile01的所有者为samlee 。
管理员root给touch命令添加SetUID权限：
再用普通用户samlee创建文件newfile02，看到如下结果：
通过这个例子，我们可以再诠释下SetUID的定义，当一个可执行文件（命令touch）设置SetUID权限后，当普通用户samlee执行touch创建新文件时，实际上是以touch命令所有者root的身份在执行此操作，既然是以root身份执行，当然新建文件的所有者为root ，这就是SetUID的作用。
再看一下与SetUID类似的SetGID权限，看一个例子，给touch命令再授予SetGID ：
此时，再使用touch创建新文件newfile03，会看到如下现象：
新建文件的所属组为touch命令的所属组，而不是执行touch命令的普通用户samlee的所属组，这就是SetGID的作用，与SetUID类似，用户在执行具有SetGID的命令时会调用命令所属组的身份。
案例二：危险的SetUID
对于SetUID的使用，可以做一个的比喻：一个绝密机关，要让一些人进来做一些事情，但是不能让他们看见机关内部的情况，于是授权一些特殊的“车辆”（没有窗户，车门紧闭，看不到外面，只有一个小洞允许乘坐的人伸出手臂做事），带着所乘坐的人开到要去的地方，允许它办完事情马上带他出来。这样是不是很安全？不一定。如果“车辆”没有经过精挑细选，可能有很多“门窗”，那可就危险了，这种类似的场景相信大家在一些警匪电影中已经见过多次了。
普通用户使用vi编辑/etc/shadow文件会提示“PermissionDenied”，这是合理的设置，但是如果赋予vi以SetUID权限：
此时，普通用户使用vi即可以编辑/etc/shadow文件，因为具备root身份，可以进行任意读写操作（比如可以把任何一个用户密码位清空，则用户登录不需要输入密码）。但是使用more、cat等命令仍然无法查看文件/etc/shadow的内容，只有被授予了SetUID的vi可以查看和修改。同样，vi如果具有了SetUID权限，普通用户可以vi编辑/etc/passwd文件把自己的UID改为0 ，则他的权限就和root一样；可以vi编辑/etc/inittab文件把缺省运行级别改成6 ，则Linux会开机后不停的重启……
再来看一个令人不安的情况，用普通用户尝试关闭Apache服务：
可以看到，普通用户不可以关闭root启动的进程，但是如果做下面一个动作：
现在当普通用户执行kill时，因为kill被授予了SetUID权限，在执行的一瞬间具有了root权限，只要用户不爽想关闭任何服务都可以！
所以，SetUID权限不能随便设置，同时要防止黑客的恶意修改，怎样避免SetUID的不安全影响，有几点建议：
1. 关键目录应严格控制写权限。比如“/”、“/usr”等；
2. 用户的密码设置要足够强壮，8位以上，大小写字母、数字、符号的组合，如：Am@ri31n，且定期更换；
3. 对系统中应该具有SetUID权限的文件作一列表，定时检查有没有这之外的文件被设置了SetUID权限。
可以对系统中应该具有SetUID权限的文件作一列表，定时检查有没有非列表中的命令被设置了SetUID权限。
在Linux安装部署完成后，执行下面命令生成SetUID列表文件：
命令find选项“-perm”为指定文件权限，SetUID权限位对应数字标识为4 ，SetGID权限位对应数字标识为2 ，后面写为“000”标识对所有者所属组其他人三类用户的权限不限制；“-o”表示or，就是文件具有SetUID或者具有SetGID都在搜索之列，生成的搜索结果存放在文件/script/setuid.list中。
在需要对系统做检查时，执行以下shell程序。也可以放在计划任务中定时检查。
假设命令kill被设置了SetUID ，则会检测提示：
另外，如果在一些数据存放的分区想禁用SetUID功能，还可以做如下设置，编辑配置文件/etc/fstab ，找到要设置的分区（如/home）所对应的设置行：
在设置“defaults”后，添加“nosuid”选项，并重新挂载/home分区：
设置后，分区/home上任何可执行文件即使被设置了SetUID权限也无法执行（读者可自行拷贝一个SetUID命令至/home目录下执行试验），在一些存放数据、用来备份等功能的分区上做此设置，可以保护系统安全。
友情提示：请您作完本文中的实验后，别忘把文件的权限恢复原状，以免带来不必要的麻烦。
至此相信读者已经对SetUID的作用有所了解，最后，还有一个大家要注意的问题，SetUID只针对具有可执行权限的文件有效，不具有x权限的文件被授予了SetUID会显示标记为S（一下子由小s变成姐姐了），仔细想一下，如果没有可执行权限的话设置SetUID无任何意义。
