主页 / unix / 问题 / 707286
Accepted
mesr
Asked: 2022-06-21 06:59:47 +0800 CST

为什么在没有完整路径的情况下找到可执行文件，尽管它的位置不在搜索路径中？

  • 772

这个问题是关于理解通过sudo调用可执行文件时记录的行为与实际行为之间感知到的不一致背后的原因。启用secure_path选项（我的系统上的默认设置）时，搜索路径的行为与预期相同。但是当该选项被禁用时，会发生一些奇怪的事情：/usr/local/bin尽管它的位置不在搜索路径中，但可以在没有完全限定路径名的情况下访问可执行文件。

系统信息

我的系统上当前安装了以下软件：

## Yeah... still haven't migrated to Alma
[me@localhost ~]$ cat /etc/centos-release
CentOS Linux release 8.5.2111

[me@localhost ~]$ bash --version | head -1
GNU bash, version 4.4.20(1)-release (x86_64-redhat-linux-gnu)

[me@localhost ~]$ sudo --version
Sudo version 1.8.29
Sudoers policy plugin version 1.8.29
Sudoers file grammar version 46
Sudoers I/O plugin version 1.8.29

[me@localhost ~]$ ssh -V
OpenSSH_8.0p1, OpenSSL 1.1.1k  FIPS 25 Mar 2021

PAM 不会在我的系统上设置或更新 PATH 变量的值：

[me@localhost ~]$ grep --recursive 'pam_env\.so' /etc/pam.d
/etc/pam.d/fingerprint-auth:auth        required      pam_env.so
/etc/pam.d/smartcard-auth:auth        required      pam_env.so
/etc/pam.d/su:auth        required    pam_env.so
/etc/pam.d/password-auth:auth        required      pam_env.so
/etc/pam.d/system-auth:auth        required      pam_env.so

[me@localhost ~]$ sudo cat /etc/security/pam_env.conf /etc/environment | grep PATH
# be useful to be set: NNTPSERVER, LESS, PATH, PAGER, MANPAGER .....
#PATH       DEFAULT=${HOME}/bin:/usr/local/bin:/bin\

我的/etc/sudoers文件为所有 sudoers 设置了一个secure_path值：

[me@localhost ~]$ sudo grep --recursive secure_path /etc/sudoers /etc/sudoers.d
/etc/sudoers:Defaults    secure_path = /sbin:/bin:/usr/sbin:/usr/bin

Bash 默认为以下 PATH 值：

[me@localhost ~]$ env --ignore-environment bash -c 'echo $PATH'
/usr/local/bin:/usr/bin

最后，我通过 SSH 连接到系统，其/etc/ssh/sshd_config文件包含以下行：

[me@localhost ~]$ sudo grep PATH /etc/sshd_config
# This sshd was compiled with PATH=/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin

复制过程

为了复制，我首先创建一个虚拟脚本并将其安装在/usr/local/bin：

[me@localhost ~]$ cat > dummy <<EOF
#!/usr/bin/bash
echo 'Found!'
EOF

[me@localhost ~]$ sudo install --owner=root --group=root --mode=755 dummy /usr/local/bin

我验证不使用sudo时搜索路径是否按预期工作：

## The /usr/local/bin location is part of my search path
[me@localhost ~]$ echo $PATH
/home/me/.local/bin:/home/me/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin

## This is expected
[me@localhost ~]$ dummy
Found!

并且使用sudo，这里也不足为奇：

## Sudo's secure_path value
[me@localhost ~]$ sudo --user=other env | grep PATH
PATH=/usr/bin:/bin:/usr/sbin:/sbin

## This is expected
[me@localhost ~]$ sudo --user=other which dummy
which: no dummy in (/sbin:/bin:/usr/sbin:/usr/bin)

## This too, of course
[me@localhost ~]$ sudo --user=other dummy
sudo: dummy: command not found

## Indeed, a fully qualified path name is required
[me@localhost ~]$ sudo --user=other /usr/local/bin/dummy
Found!

然后，我禁用secure_path（这里要小心！建议使用visudo），方法是注释掉该行/etc/sudoers或创建一个/etc/sudoers.d/local包含以下行的文件：

# Disable secure_path if set
Defaults !secure_path

这应该可以防止sudo在使用开关调用时用--preserve-env值secure_path覆盖 PATH 环境变量。它按预期工作。

但是，当不使用该--preserve-env开关，并且不使用该开关提示一个完整的登录序列--login（因此不获取任何 Bash 的启动文件），并且在任何 PAM 环境文件中没有分配给 PATH 时，会发生一些奇怪的事情：

## Not sure where this PATH value is from, neither from sudo's secure_path option
## (not set), PAM environment files (contain no assignment to PATH), Bash startup
## scripts (not sourced), nor Bash or sshd default PATH values (no match).
[me@localhost ~]$ sudo --user=other env | grep PATH
PATH=/usr/bin:/bin:/usr/sbin:/sbin

## Regardless, this is expected
[me@localhost ~]$ sudo --user=other which dummy
which: no dummy in (/usr/bin:/bin:/usr/sbin:/sbin)

## But wait! What?!?
[me@localhost ~]$ sudo --user=other dummy
Found!

那么，如何在直接调用没有路径前缀的情况下which dummy抱怨dummy不在搜索路径中呢？dummy

相关文件

以下是对我在研究此问题时发现相关的各种信息的引用。

Sudo 文档说明了有关secure_path选项的内容：

用于从 sudo 运行的每个命令的路径。如果你不相信运行 sudo 的人有一个健全的 PATH 环境变量，你可能想要使用它。另一个用途是，如果您想让“根路径”与“用户路径”分开。exclude_group 选项指定的组中的用户不受secure_path 的影响。默认情况下未设置此选项。

根据手册页中的pam_env文档，默认情况下pam_env模块仅应处理 、/etc/environment和/etc/security/pam_env.conf，除非指定了非默认文件名。在我的系统上不是这种情况，这些文件都没有设置或更新 PATH 的值。~/.pam_environment

Bash 的手册页说：

PATH 命令的搜索路径。它是一个以冒号分隔的目录列表，shell 在其中查找命令（请参阅下面的命令执行）。PATH 值中的零长度（空）目录名称表示当前目录。空目录名称可能显示为两个相邻的冒号，或者显示为初始冒号或尾随冒号。默认路径取决于系统，由安装 bash 的管理员设置。一个常见的值是“/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin”。

这个 gnu.org 上的 Bash 文档页面 ( https://www.gnu.org/software/bash/manual/html_node/Bash-Startup-Files.html ) 解释了各种启动文件的来源。在我上面的演示中，不应获取这些文件，因为我既没有在--loginor中生成新的 shell，也没有使用开关--interactive调用sudo 。--login

这个 ServerFault 答案（https://serverfault.com/questions/833762/where-does-the-bash-path-on-centos-7-get-usr-local-bin-from#answer-838552）解释了 Bash 的默认值对于 PATH 变量。即使在 CentOS 7 上回答了 Bash，该答案仍然与 CentOS 8 打包的 Bash 版本相关。根据接受的答案，bash 源代码config-top.h如下：

/* The default value of the PATH variable. */
#ifndef DEFAULT_PATH_VALUE
#define DEFAULT_PATH_VALUE \
  "/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:."
#endif

/* The value for PATH when invoking `command -p'.  This is only used when
   the Posix.2 confstr () function, or CS_PATH define are not present. */
#ifndef STANDARD_UTILS_PATH
#define STANDARD_UTILS_PATH \
  "/bin:/usr/bin:/sbin:/usr/sbin:/etc:/usr/etc"
#endif
bash sudo

1 个回答

  1. Best Answer

    我相信你看到了env_reset和之间的相互作用secure_path。

    启用时：

    • secure_path重置PATH为已知良好的值
    • env_reset重置大多数环境变量，包括PATH（确切的行为将取决于其他选项和配置，包括secure_path）

    问题是：每次重置会影响什么？

    第二，env_reset影响启动的程序sudo。另一方面，secure_path也影响到sudo自己。没有它，sudo使用（调用）用户PATH查找程序。但：

    • 启动程序时，
      • 如果env_reset启用（默认），并且
        • PATH不能免于被重置（例如，通过env_keep），那么，
          • 该程序将从...开始
            • 的复位值PATH
            • （以及其他环境变量）

    因此，当您打电话which或env其他事情时，它不会看到PATH它sudo本身正在使用的东西。

    • 1

相关问题