☰

Linux 命令“id”和“whoami”依赖项（用于 chroot 环境）

tag-icon • tag-icon linux ssh chroot
Linux 命令“id”和“whoami”依赖项（用于 chroot 环境）

我在 Fedora Core 18 中拥有一个新的 openssh (openssh-server-6.1p1-4.fc18.i686) chroot 环境，并将用户置于带有 (bash) shell 的 chroot 目录结构中。在故障排除过程中，SELinux 一直处于宽容模式，以排除它是问题的原因。

登录时用户会看到以下内容：

Using username "testuser".

Authenticating with public key "rsa-key-xxxxxxx" from agent
id: cannot find name for group ID 1002
id: cannot find name for user ID 1001
id: cannot find name for group ID 1002
id: cannot find name for user ID 1001
[I have no name!@fc18test ~]$

Whoami 也以类似的方式失败了。

id 命令在此 chroot 环境中正常工作需要哪些依赖项？它在以前版本的 Fedora 中使用旧版本的 OpenSSH 时可以正常工作。

在 chroot 环境中，/etc 目录已使用 passwd 和 passwd-、group 和 group- 以及 nsswitch.conf 重新创建。nsswitch.conf 将“passwd”和“group”的条目定义为“文件”，并且用户 ID 和组 ID 都存在于相应的文件中。文件权限与标准 /etc 目录中相同文件的权限相同。SELinux 上下文也匹配，尽管这没有必要，因为 SELinux 在故障排除时处于宽容模式。

我认为 id 调用了getuid()或geteuid()。我是否可能缺少 chroot/lib目录中的库？

有人能解释一下出了什么问题吗？

答案1

使用LDD检查链接库，例如：

 $ ldd $(which  whoami)
    linux-vdso.so.1 =>  (0x00007fff00bfe000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa25f48e000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fa25f871000)

如果你在系统上找不到 linux-vdso，不要担心，例如：

您看到的 linux-vdso.so.1 库是一个虚拟库或虚拟动态共享对象，它仅驻留在每个程序的地址空间中。较旧的系统将其称为 linux-gate.so.1。此虚拟库提供必要的逻辑，以允许用户程序通过特定处理器上可用的最快方式（中断或大多数较新的处理器上的快速系统调用）访问系统功能。

答案2

谢谢提示:)

原因在于whoami依赖于nss查找用户和组。

我使用的解决方案是跟踪 whoami 调用：

/ # strace /bin/whoami
....
socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
connect(3, {sa_family=AF_LOCAL, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
close(3)                                = 0
open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/libnss_compat.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
write(2, "/bin/whoami: cannot find name fo"..., 44/bin/whoami: cannot find name for user ID 0) = 44
close(1)                                = 0
close(2)                                = 0
exit_group(1)                           = ?
+++ exited with 1 +++

通过复制丢失的库文件解决了这个问题。

相关内容