我已经剖析了Google的非破坏性图像，以了解它们是如何构建的，但我的公司希望拥有我们自己构建的图像。
看起来Google会在其基本映像中构建glibc，libssl和openssl，所以我也做同样的事情。我添加了一个静态链接的busybox，curl和sudo进行测试。但是，当我以用户身份登录时，sudo告诉我它无法读取系统上存在的库。起初我以为它与root的环境有关，因为setuid但passwd也是setuid并且可以工作。
以下是一些输出：
Distroless [gdanko@5bd77574a894]:~ $ ldd /usr/bin/sudo
linux-vdso.so.1 (0x00007fff5e728000)
libutil.so.1 => /lib64/libutil.so.1 (0x00007f4bf61a1000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f4bf5f6a000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f4bf5d4c000)
libc.so.6 => /lib64/libc.so.6 (0x00007f4bf59b3000)
/lib64/ld-linux-x86-64.so.2 (0x00007f4bf6621000)
Distroless [gdanko@5bd77574a894]:~ $ ls -l /lib64/libutil.so.1
lrwxrwxrwx 1 root root 15 Oct 2 17:45
/lib64/libutil.so.1 -> libutil-2.25.so
Distroless [gdanko@5bd77574a894]:~ $ ls -l /lib64/libcrypt.so.1
lrwxrwxrwx 1 root root 16 Oct 2 17:45
/lib64/libcrypt.so.1 -> libcrypt-2.25.so
Distroless [gdanko@5bd77574a894]:~ $ ls -l /lib64/libpthread.so.0
lrwxrwxrwx 1 root root 18 Oct 2 17:45
/lib64/libpthread.so.0 -> libpthread-2.25.so
Distroless [gdanko@5bd77574a894]:~ $ ls -l /lib64/libc.so.6
lrwxrwxrwx 1 root root 12 Oct 2 17:45
/lib64/libc.so.6 -> libc-2.25.so
Distroless [gdanko@5bd77574a894]:~ $ sudo
sudo: error while loading shared libraries: libutil.so.1: cannot open
shared object file: No such file or directory
如果我su-root并执行sudo可以正常工作
Distroless [gdanko@5bd77574a894]:~ $ su - root
Password:
Distroless [root@5bd77574a894]:~ # sudo
usage: sudo -h | -K | -k | -V
usage: sudo -v [-AknS] [-g group] [-h host] [-p prompt] [-u user]
usage: sudo -l [-AknS] [-g group] [-h host] [-p prompt] [-U user] [-u user] [command]
usage: sudo [-AbEHknPS] [-C num] [-g group] [-h host] [-p prompt] [-T timeout] [-u user] [VAR=value] [-i|-s] [<command>]
usage: sudo -e [-AknS] [-C num] [-g group] [-h host] [-p prompt] [-T timeout] [-u user] file ...
我想知道这是否与Google如何构建glibc有关，但是我找不到任何明显的地方。
另一件事是，如果我使用Google的distroless基础作为图像并复制sudo，则busybox可以在容器中工作。我尝试了多种尝试来解决此问题的方法，但是我很茫然。谁能看到我可能会丢失的东西？