概述
问题描述
今天在测试文件系统的时候,发现新创建的文件系统不能使用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
最后
以上就是甜美巨人为你收集整理的sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set的全部内容,希望文章能够帮你解决sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set所遇到的程序开发问题。
如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。
发表评论 取消回复