linux下sudo显示sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set

转载：https://blog.csdn.net/mountzf/article/details/52033348

 

linux中一些特殊的权限（setuid/setgid/sticky）

问题描述

今天在测试文件系统的时候，发现新创建的文件系统不能使用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

• 1
• 2

相对应的就是上述两个错误：sudo的用户属组要属于uid 0，即root用户；同时sudo要设置setuid位。我首先查询了一下我系统中sudo的信息：

ls /usr/bin/sudo
-rwxr-xr-x 1 root root 155008 Aug 28  2015 /usr/bin/sudo

• 1
• 2

已经是输入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

• 1
• 2

发现有一位”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

• 1
• 2
• 3

具有setuid属性的程序为-rwsr-xr-x。

授予setgid权限

chmod g+s dir1
or
chmod 2xxx dir1

• 1
• 2
• 3

具有setgid属性的目录为drwxrwsr-x。

授予sticky权限

chmod t dir1
or
chmod 1xxx dir1

• 1
• 2
• 3

具有sticky属性的目录为drwxrwxrwt。