默认日志不记录完整命令参数，因sudo默认仅记录元信息（如用户、目标用户、是否成功），而COMMAND=后参数被截断以避免敏感信息泄露；需同时配置Defaults logfile和log_input/log_output才能实现精准审计。
默认日志不记录完整命令参数，必须显式配置才能精准审计每个 sudo 命令的完整执行内容。
为什么 auth.log 或 secure 里看不到完整命令？
系统默认只记录 sudo 行为的元信息（如用户、目标用户、是否成功），但不会记录 COMMAND= 后的完整参数。例如执行 sudo cp /tmp/a.conf /etc/nginx/，日志可能只显示 sudo: user : TTY=pts/0 ; PWD=/home/user ; USER=root ; COMMAND=/bin/cp，丢掉了源路径和目标路径。
- 这是 sudo 的默认安全策略：避免敏感参数（如密码、密钥路径）被无意写入系统日志
- Debian/Ubuntu 的
/var/log/auth.log和 RHEL/CentOS 的/var/log/secure都受此限制 - 仅靠
grep "COMMAND="无法还原真实操作意图
启用完整命令审计的两个必要配置项
必须同时设置以下两项，缺一不可：
-
Defaults logfile=/var/log/sudo.log：强制 sudo 自己写日志到独立文件，绕过 syslog 的截断逻辑 -
Defaults log_input,log_output（可选但推荐）：记录 stdin/stdout/stderr，配合sudo_logsrvd可回放操作过程
编辑 /etc/sudoers 时务必用 visudo，避免语法错误锁死 sudo：
sudo visudo # 在文件末尾添加两行： Defaults logfile=/var/log/sudo.log Defaults log_input,log_output
保存后，/var/log/sudo.log 就会开始记录带完整参数的命令，例如：
Browser Setup (No-Root Linux)
下载
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
Sept 28 17:23:41 host sudo: user : TTY=pts/1 ; PWD=/home/user ; USER=root ; COMMAND=/bin/mv /tmp/deploy.tar.gz /opt/app/
日志路径与权限要注意什么？
/var/log/sudo.log 默认由 root 创建并拥有，普通用户无法读取——这既是安全设计，也是排查盲点：
- 确保日志目录存在且权限合理：
sudo mkdir -p /var/log && sudo chown root:root /var/log/sudo.log && sudo chmod 600 /var/log/sudo.log - 如果使用 rsyslog 转发，需在
/etc/rsyslog.conf中加local2.* /var/log/sudo.log并重启rsyslog，否则日志可能被吞掉或写错位置 - CentOS 6 等旧系统中，
log_input需要sudo版本 ≥ 1.8.5，低于此版本即使配置也无效
查不到命令？先确认 sudo 是否真在记录
常见失效场景比想象中多：
- 用户用
sudo -i或sudo su -进入 shell 后执行的命令，不会被 sudo 日志记录——日志只捕获sudo cmd这一层调用 - 某些发行版（如 Alpine）默认不编译
log_input支持，sudo -V | grep -i log查看输出是否含log_input -
sudoers中某条规则用了NOPASSWD:但没继承全局Defaults，会导致该规则下的命令跳过日志（需显式在规则行末加LOG_INPUT）
验证是否生效最直接的方式：sudo echo test && sudo tail -n1 /var/log/sudo.log，看到带完整 COMMAND= 的条目才算真正跑通。
真正麻烦的不是配置，而是日志分散：一个用户可能走 /var/log/sudo.log，另一个走 /var/log/secure，还有一个通过堡垒机跳转——审计前得先理清所有入口路径，否则漏一条就等于没审。
