Linux怎么限制用户sudo执行特定命令

P粉602998670

发布时间：2025-09-11 11:04:01

878人浏览过

来源于php中文网

原创

最核心方式是通过visudo编辑/etc/sudoers文件实现命令级权限控制。首先定义命令别名（如cmnd_alias nginx_restart），再为用户或组（如devuser或%devops）分配精确执行权限，支持nopasswd选项提升效率。推荐使用白名单机制明确允许特定命令，避免黑名单遗漏风险。配置时需警惕shell逃逸、环境变量操纵、通配符滥用和符号链接绕过等安全陷阱。可通过sudo -l验证权限分配，实际测试允许与禁止命令的执行效果。务必使用visudo确保语法正确，并备份原文件以防失效。若sudo失效，可借助单用户模式或live usb修复。基于用户组的权限管理更利于企业环境维护，规则应按顺序合理排列，防止宽泛规则覆盖具体限制。

linux怎么限制用户sudo执行特定命令

在Linux系统里，要限制用户通过

sudo

执行特定命令，最核心且权威的方式就是编辑

/etc/sudoers

文件。这允许你对用户的权限进行精细到命令级别的控制，确保他们只能执行被授权的操作，而不能滥用

sudo

权限。

解决方案

限制

sudo

命令，我们主要通过

/etc/sudoers

文件来配置。这个文件定义了哪些用户或用户组可以以何种身份（通常是

root

）执行哪些命令，以及是否需要输入密码。编辑这个文件，务必使用

visudo

命令，它会在保存前检查语法错误，防止你因为配置失误而把自己锁在

sudo

权限之外。

基本思路是：

定义命令别名 (Cmnd_Alias)：将一组相关命令打包，方便管理。
为用户或组分配权限：指定哪些用户或用户组可以执行哪些命令别名，或者直接指定命令。

举个例子，假设我们有一个开发人员

devuser

，他需要重启

nginx

服务，但不能随意执行其他系统管理命令。

首先，打开终端并运行

sudo visudo

。

sudo visudo

在文件里，你可以找到类似这样的行：

# User privilege specification
root    ALL=(ALL:ALL) ALL

这表示

root

用户可以执行所有命令。

现在，我们来为

devuser

配置。

场景一：允许特定命令，禁止其他

如果

devuser

只需要重启

nginx

，我们可以这样定义：

# 定义一个命令别名，包含允许执行的命令
Cmnd_Alias NGINX_RESTART = /usr/bin/systemctl restart nginx

# 为 devuser 分配权限，允许他以root身份执行 NGINX_RESTART 中的命令，且无需密码
devuser ALL=(root) NOPASSWD: NGINX_RESTART

这里

NOPASSWD:

是一个选项，表示执行这些命令时不需要输入

devuser

自己的密码。我个人觉得，对于一些低风险、高频的操作，

NOPASSWD

确实能提升效率，但安全起见，通常还是建议保留密码验证。

场景二：禁止特定命令

有时候，你可能想给用户大部分

sudo

权限，但明确禁止某些危险操作。这在实际工作中挺常见的，比如给一个初级管理员大部分权限，但绝对不让他

rm -rf /

。

# 定义一个命令别名，包含禁止执行的命令
Cmnd_Alias DANGEROUS_CMDS = /usr/bin/rm, /usr/bin/sh, /usr/bin/bash, /usr/sbin/fdisk, /usr/sbin/mkfs

# 假设 devuser 已经有了一些权限，我们可以在其权限行后加上禁止的命令
# 注意：DENY 规则通常要放在 ALLOW 规则之前，或者使用 ! 符号
# 这是一个更常见的做法，先允许所有，再排除特定命令
devuser ALL=(ALL) ALL, ! DANGEROUS_CMDS

这条规则的意思是

devuser

可以执行所有命令，但不能执行

DANGEROUS_CMDS

里定义的命令。不过，这种“先全部允许再排除”的方式，我个人觉得风险还是比较高，因为你很难穷举所有危险命令。相比之下，明确列出允许的命令（白名单）会更安全、更可控。

配置完成后，保存并退出

visudo

。

visudo

会自动检查语法，如果没问题就保存，有问题则会提示你修改。

限制

sudo

命令时，有哪些常见的陷阱或错误？

说实话，配置

sudoers

文件远不是看起来那么简单，一不小心就可能留下安全漏洞，或者把自己锁死。在我看来，最大的陷阱往往不是语法错误，而是对命令执行环境和潜在绕过方式的理解不足。

Shell 逃逸 (Shell Escapes)：这是最经典的陷阱。你可能允许用户
```
sudo vi /etc/hosts
```
，觉得
```
vi
```
没什么危险。但
```
vi
```
、
```
less
```
、
```
more
```
等许多交互式程序都允许在内部执行 shell 命令（例如在
```
vi
```
中输入
```
:!bash
```
）。如果用户能
```
sudo vi
```
，他们就能通过
```
vi
```
内部的 shell 逃逸到
```
root
```
权限的 shell。所以，如果你允许用户执行一个交互式程序，你需要非常小心这个程序是否能提供 shell 逃逸的途径。
环境变量操纵 (Environment Variables)：用户可以通过设置
```
PATH
```
环境变量，让
```
sudo
```
执行看起来无害但实际上被替换的命令。例如，你允许用户
```
sudo /usr/bin/ls
```
，但用户可以创建一个名为
```
ls
```
的恶意脚本，并将其放在
```
PATH
```
靠前的位置。当他执行
```
sudo ls
```
时，可能就会执行到他的恶意脚本。为了避免这种情况，
```
sudo
```
默认会清理或限制一些关键环境变量，但仍需注意
```
secure_path
```
的设置。

Shell脚本编写基础中文WORD版
Shell本身是一个用C语言编写的程序，它是用户使用Linux的桥梁。Shell既是一种命令语言，又是一种程序设计语言。作为命令语言，它交互式地解释和执行用户输入的命令；作为程序设计语言，它定义了各种变量和参数，并提供了许多在高级语言中才具有的控制结构，包括循环和分支。它虽然不是Linux系统核心的一部分，但它调用了系统核心的大部分功能来执行程序、建立文件并以并行的方式协调各个程序的运行。因此，对于用户来说，shell是最重要的实用程序，深入了解和熟练掌握shell的特性极其使用方法，是用好Linux系统

下载
通配符的滥用 (Wildcard Misuse)：使用通配符（如
```
*
```
）来匹配命令路径时要格外小心。比如
```
Cmnd_Alias MY_SCRIPTS = /usr/local/bin/*
```
看起来很方便，但如果
```
/usr/local/bin
```
下面出现了一个恶意脚本，并且被
```
devuser
```
运行了，那麻烦就大了。尽可能使用完整的命令路径，或者对通配符匹配的目录有严格的写入权限控制。
符号链接 (Symlinks)：用户可能会创建符号链接来绕过命令限制。比如你禁止
```
sudo /bin/bash
```
，但用户创建了一个
```
ln -s /bin/bash /tmp/mybash
```
，然后尝试
```
sudo /tmp/mybash
```
。
```
sudo
```
默认情况下会跟随符号链接，所以这种方式可能会绕过你的限制。解决办法通常是确保限制的命令路径是真实的，并且用户没有权限创建指向危险命令的符号链接。
不完整的限制：你可能只限制了
```
rm
```
命令，但忘记了
```
shred
```
或者
```
dd
```
也能达到类似破坏性效果。在做白名单（只允许特定命令）时，要确保你确实列出了所有必要且安全的命令。黑名单（禁止特定命令）则更难做到万无一失。

我个人在配置

sudoers

时，最怕的就是那种“自以为安全”的配置。每次都会反复思考：如果我是一个想搞破坏的用户，我会怎么绕过这个限制？这种逆向思维，虽然有点让人头疼，但确实能帮助发现潜在的漏洞。

如何为不同用户组设置不同的

sudo

限制？

在实际的企业环境中，给每个用户单独配置

sudo

权限是件很低效且容易出错的事。更合理、更可维护的方式是利用用户组。

sudoers

文件天生就支持基于组的权限管理，这极大地简化了权限的分配和回收。

基本语法是使用

符号来指代用户组。

假设我们有两个用户组：

devops

和

dba

。

```
devops
```
组的成员需要重启各种服务（如
```
nginx
```
,
```
php-fpm
```
,
```
redis
```
）。
```
dba
```
组的成员需要执行一些数据库相关的管理命令（如
```
mysqladmin
```
,
```
pg_ctl
```
）。

首先，确保这些用户组已经在系统中创建，并且相应的用户已经加入到这些组中。

# 创建用户组（如果不存在）
sudo groupadd devops
sudo groupadd dba

# 将用户添加到组中
sudo usermod -aG devops your_devops_user
sudo usermod -aG dba your_dba_user

然后，再次使用

sudo visudo

编辑

/etc/sudoers

文件。

我们可以这样定义：

# 定义 devops 组的命令别名
Cmnd_Alias SERVICE_RESTARTS = /usr/bin/systemctl restart nginx, \
                               /usr/bin/systemctl restart php-fpm, \
                               /usr/bin/systemctl restart redis

# 定义 dba 组的命令别名
Cmnd_Alias DB_ADMIN_CMDS = /usr/bin/mysqladmin *, \
                           /usr/bin/pg_ctl *, \
                           /usr/bin/mysqldump *

# 为 devops 组分配权限
%devops ALL=(root) NOPASSWD: SERVICE_RESTARTS

# 为 dba 组分配权限
%dba ALL=(root) NOPASSWD: DB_ADMIN_CMDS

这里有几点值得注意：

多行命令别名：如果一个命令别名包含很多命令，你可以使用反斜杠
```
\
```
来进行换行，让配置更易读。
NOPASSWD:
的使用：再次强调，根据实际需求决定是否使用
```
NOPASSWD:
```
。对于服务重启这类操作，为了自动化或快速响应，
```
NOPASSWD
```
是常见的选择。
规则的顺序：
```
sudoers
```
文件中的规则是按顺序匹配的，一旦匹配成功，后续的规则就不会再被评估。这意味着，如果你有一个宽泛的规则（例如
```
ALL=(ALL) ALL
```
），后面跟着一个更具体的限制，那么宽泛的规则可能会“覆盖”掉你的具体限制。所以，通常的建议是把最具体的、限制性最强的规则放在前面，或者确保你的规则设计不会互相冲突。

通过这种方式，当有新成员加入

devops

组时，他们会自动获得重启服务的

sudo

权限，而无需单独修改

sudoers

文件。这极大地提升了管理效率和一致性。

如何测试和验证

sudoers

配置是否生效？

配置完

sudoers

文件后，最重要的一步就是测试和验证，确保你的配置达到了预期效果，并且没有引入新的问题（比如不小心把自己锁在

sudo

权限之外）。我个人觉得，任何对权限配置的修改，都必须经过严格的测试，否则简直就是给自己挖坑。

使用
```
sudo -l
```
命令：这是最直接的检查方式。以目标用户的身份登录（或者使用
```
su - target_user
```
切换到该用户），然后运行：
```
sudo -l
```
这个命令会列出当前用户（或指定用户）被允许执行的所有
```
sudo
```
命令，以及是否需要密码。通过查看输出，你可以快速确认你的配置是否被正确解析。

例如，如果你为
```
devuser
```
配置了
```
NGINX_RESTART
```
别名：
```
# 以 devuser 身份运行
sudo -l
```
你可能会看到类似这样的输出：
```
User devuser may run the following commands on this host:
    (root) NOPASSWD: /usr/bin/systemctl restart nginx
```
这表明
```
devuser
```
确实被允许以
```
root
```
身份无密码执行
```
systemctl restart nginx
```
。
实际执行命令测试：光看
```
sudo -l
```
的输出还不够，你还需要实际去尝试执行那些被允许和被禁止的命令。
- 测试允许的命令：以
```
devuser
```
  身份执行
```
sudo /usr/bin/systemctl restart nginx
```
  ，看它是否能成功执行。
- 测试禁止的命令：如果你的配置禁止了
```
rm
```
  ，那么以
```
devuser
```
  身份尝试执行
```
sudo rm /etc/hosts
```
  ，看它是否会被拒绝。你应该会看到类似 "is not allowed to execute..." 的错误信息。
注意
```
visudo
```
的重要性：再次强调，始终使用
```
visudo
```
编辑
```
/etc/sudoers
```
文件。
```
visudo
```
会在保存前对语法进行严格检查。如果你的配置有语法错误，
```
visudo
```
会提示你并阻止你保存，这能有效防止你因为错误的配置导致
```
sudo
```
彻底失效，把自己锁在系统之外。
备份
```
sudoers
```
文件：在进行任何重大修改之前，养成备份
```
/etc/sudoers
```
文件的习惯是极其重要的。一个简单的
```
sudo cp /etc/sudoers /etc/sudoers.bak
```
就能在出现问题时救你一命。
如果
```
sudo
```
真的失效了怎么办？ 如果万一你没有使用
```
visudo
```
，或者
```
visudo
```
没能捕获到所有逻辑错误，导致
```
sudo
```
命令对所有用户（包括
```
root
```
）都失效了，别慌，还有补救措施：
- 单用户模式 (Single User Mode)：重启你的Linux系统，在引导加载器（如GRUB）界面选择进入单用户模式（或恢复模式）。在这种模式下，你通常会以
```
root
```
  身份登录，并且文件系统会以读写模式挂载。这样你就可以直接编辑
```
/etc/sudoers
```
  文件来修复错误。
- Live CD/USB：如果单用户模式也无法访问，你可以使用一个Linux Live CD/USB启动你的机器，然后挂载你的系统分区，手动编辑
```
/etc/sudoers
```
  文件。