4

So, I'm trying to build musl-libc inside an Alpine Linux Docker container. The configure script succeeds, but make stops immediately because it can't run mkdir:

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

Using strace, I can see that it's getting EPERM when it checks access on the various mkdir symlinks, so it never actually runs the command itself:

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)

I have no idea why this is. I'm running make as root, and /bin/busybox has the executable bit set for all users anyway. I can create the directory just fine from the command line. What's going on here, and how do I fix it?

EDIT: As requested, here's the Dockerfile I'm using:

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

Requires the musl source in ./musl-src.

George Hodgkins
  • 69
  • 2
  • 9
  • Nah, looks like +x is set on / (and /bin). I added the Dockerfile above. – George Hodgkins Jul 07 '21 at 00:05
  • 1
    BTW, it's not just `mkdir`. Edit `musl-src/Makefile` to call any other command (`ls`, `cat`, etc) and it'll fail the same way. – Charles Duffy Jul 07 '21 at 00:32
  • 4
    Heh, think I've found it. Look at https://github.com/moby/moby/blob/19.03/profiles/seccomp/default.json -- `faccessat` is in the list of permitted syscalls, but not `faccessat2`. – Charles Duffy Jul 07 '21 at 01:46
  • 1
    This is https://github.com/moby/moby/pull/41381 – Charles Duffy Jul 07 '21 at 01:49
  • 1
    Nice! Updating to Docker 19.06+ (latest/beta channel on Ubuntu) fixed it for me. If you put this as an answer I'll accept it. – George Hodgkins Jul 07 '21 at 13:55
  • 1
    I remembered having seen something very much like this question before, and looking at it, the prior instance was https://stackoverflow.com/questions/48995826/which-capabilities-are-needed-for-statx-to-stop-giving-eperm. I'd argue that this is better closed as duplicate than answered; no reason to have more than one instance. – Charles Duffy Jul 07 '21 at 17:09
  • I'd strongly argue against closing this as duplicate, whilst https://stackoverflow.com/questions/48995826 explains the underlying cause it's way too low-level and I'd never have found it in a search. On the other hand, this one precisely matched the issue I was having and was one of the top search results. – Ed Randall Feb 01 '22 at 07:47

1 Answers1

1

Workaround: use bmake instead of make

I hit this exact same problem in a containerised build on Alpine where make was GNU make 4.3. The build would work fine on local Docker but fail on the ADO pipeline agents. Alternatively the same sequence of commands that make was attempting, issued directly from RUN, also worked fine.

The pipeline agents are based on RHEL7 with the Docker version that RH choose to package. I can't upgrade Docker on them, nor start it using special options and a different security profile. It's managed by a different team and right out of my control.

With reference to comments above and the other question Which capabilities are needed for statx to stop giving EPERM it seems reasonable to guess that an alternate implementation of make might use the older stat rather than statx call which this old version of Docker has trouble with.

Indeed, NetBSD's bmake gives me a solution for now.

RUN apk add --upgrade gcc libc-dev bmake

RUN bmake dist
Ed Randall
  • 6,887
  • 2
  • 50
  • 45