问题描述
今天在测试文件系统的时候，发现新创建的文件系统不能使用sudo命令，具体表现如下：
sudo su
sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set
1
2
在网上查了一下都说是要在超级用户权限下执行如下两个命令：
chown root:root /usr/bin/sudo
chmod 4755 /usr/bin/sudo
相对应的就是上述两个错误：sudo的用户属组要属于uid 0，即root用户；同时sudo要设置setuid位。我首先查询了一下我系统中sudo的信息：
ls /usr/bin/sudo
-rwxr-xr-x 1 root root 155008 Aug 28 2015 /usr/bin/sudo
已经是输入root用户组了，所以按照执行sudo时的错误提示，应该是要设置setuid位。执行命令chmod 4755 /usr/bin/sudo或者chmod u+s /usr/bin/sudo，再查看一下sudo的信息：
ls /usr/bin/sudo
-rwsr-xr-x 1 root root 155008 Aug 28 2015 /usr/bin/sudo
发现有一位”x”已经变成了”s”。这时我想起了在学习The Linux Command Line的时候，提到了一些特殊的用户权限，其中就包括设置setuid位。翻出来看看，学而时习之嘛~
特殊权限
虽然常见的八进制权限掩码都是用三位数表示的，但确切地说，它是用四位数表示的，因为除了读、写和执行权限以外，还有一些其他较少用到的权限设置，其中就涉及到上面的setgid设置。
setuid
其中之一就是setuid位，八进制表示为4000，当把它应用到一个可执行文件时，有效用户ID将从实际用户ID（实际运行该程序的用户）设置成该程序所有者的ID，大多数情况下，该权限设置通常应用于一些由超级用户所拥有的程序，例如本问题中的sudo。当普通用户运行一个具有“setuid root”（已设置setuid位，由root用户所有）属性的程序时，该程序将以超级用户的权限执行。
setgid
第二个是setgid位，八进制表示为2000，类似于setuid，它会把有效用户组ID从该用户的实际组ID更改为该文件所有者的组ID。如果对一个目录设置setgid位，那么在该目录下创建的文件将由该目录所在组所有，而不属于文件创建者所在组。当一个公共组下的成员需要访问共享目录下的所有文件时，设置setgid位将会很有用，并不需要关注文件所有者所在的用户组。
sticky
第三个是sticky位，八进制表示位1000，它是从UNIX中继承下来的，在LINUX中将会忽略文件的sticky位。但是对一个目录设置sticky位，那么将能阻止用户删除或者重命名文件，除非用户是这个目录的所有者、文件所有者或者超级用户。它通常用来控制对共享目录（例如/tmp）的访问。
设置方法
授予setuid权限
chmod u+s prog1
or
chmod 4xxx prog1
具有setuid属性的程序为-rwsr-xr-x。
授予setgid权限
chmod g+s dir1
or
chmod 2xxx dir1
具有setgid属性的目录为drwxrwsr-x。
授予sticky权限
chmod t dir1
or
chmod 1xxx dir1
具有sticky属性的目录为drwxrwxrwt。
————————————————
版权声明：本文为CSDN博主「mountzf」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/mountzf/article/details/52033348