Make 无法在 Alpine Linux 容器中以 root 身份运行 mkdir答案

【问题标题】：Make can't run mkdir as root in Alpine Linux containerMake 无法在 Alpine Linux 容器中以 root 身份运行 mkdir
【发布时间】：2021-07-06 20:49:55
【问题描述】：

所以，我正在尝试在 Alpine Linux Docker 容器中构建 musl-libc。 configure脚本成功了，但是make因为不能运行mkdir而立即停止：

mkdir -p lib
make: mkdir: Operation not permitted
make: *** [Makefile:96: lib] Error 127

使用 strace，我可以看到它在检查各种 mkdir 符号链接的访问权限时获得了 EPERM，因此它从未实际运行命令本身：

faccessat2(AT_FDCWD, "/usr/local/sbin/mkdir", X_OK, AT_EACCESS) = -1 EPERM (Operation not permitted)
faccessat2(AT_FDCWD, "/usr/local/bin/mkdir", X_OK, AT_EACCESS) = -1 EPERM (Operation not permitted)
faccessat2(AT_FDCWD, "/usr/sbin/mkdir", X_OK, AT_EACCESS) = -1 EPERM (Operation not permitted)
faccessat2(AT_FDCWD, "/usr/bin/mkdir", X_OK, AT_EACCESS) = -1 EPERM (Operation not permitted)
faccessat2(AT_FDCWD, "/sbin/mkdir", X_OK, AT_EACCESS) = -1 EPERM (Operation not permitted)
faccessat2(AT_FDCWD, "/bin/mkdir", X_OK, AT_EACCESS) = -1 EPERM (Operation not permitted)

我不知道这是为什么。我以 root 身份运行 make，/bin/busybox 无论如何都为所有用户设置了可执行位。我可以从命令行很好地创建目录。这是怎么回事，我该如何解决？

编辑：根据要求，这是我正在使用的 Dockerfile：

FROM alpine

ENV UTILS='vim tmux gdb strace git mandoc'
ENV DEPS='gcc make'

RUN apk update && apk add $DEPS $UTILS
ADD musl-src /musl-libc
ENV NPROC=6
RUN cd musl-libc && ./configure --prefix=/usr --enable-debug && \
    make -j$NPROC
RUN cd musl-libc && make install

需要./musl-src中的musl源代码。

【问题讨论】：

顺便说一句，不仅仅是mkdir。编辑 musl-src/Makefile 以调用任何其他命令（ls、cat 等），它会以同样的方式失败。
嘿，我想我找到了。查看github.com/moby/moby/blob/19.03/profiles/seccomp/default.json -- faccessat 在允许的系统调用列表中，但不在faccessat2 中。
这是github.com/moby/moby/pull/41381
不错！更新到 Docker 19.06+（Ubuntu 上的最新/beta 频道）为我修复了它。如果您将此作为答案，我会接受。
我记得以前看过很像这个问题的东西，看了看，之前的例子是stackoverflow.com/questions/48995826/…。我认为这比回答更好地关闭为重复；没有理由拥有多个实例。

标签： docker makefile alpine musl

【解决方案1】：

解决方法：使用 bmake 代替 make

我在 Alpine 上的容器化构建中遇到了同样的问题，其中 make 是 GNU make 4.3。该构建在本地 Docker 上可以正常工作，但在 ADO 管道代理上会失败。或者，直接从 RUN 发出的 make 尝试的相同命令序列也可以正常工作。

管道代理基于 RHEL7 和 RH 选择打包的 Docker 版本。我无法在它们上升级 Docker，也无法使用特殊选项和不同的安全配置文件启动它。它由不同的团队管理，完全不受我的控制。

参考上面的 cmets 和另一个问题 Which capabilities are needed for statx to stop giving EPERM，猜测 make 的替代实现可能使用旧的 stat 而不是 statx 调用似乎是合理的，这个旧版本的 Docker 遇到了麻烦.

确实，NetBSD 的bmake 给了我一个解决方案。

RUN apk add --upgrade gcc libc-dev bmake

RUN bmake dist

【讨论】：