ch-build --force=seccomp can’t install systemd

[reidpr]

Our good friend systemd can’t be installed in a Debian Bullseye container:

$ printf 'FROM debian:11\nRUN apt-get update && apt-get upgrade -y\nRUN apt-get install -y systemd\n' | ch-image build --force -t foo -
  1. FROM debian:11
[...]
Setting access ACL "u::rwx,g::r-x,g:adm:r-x,m::r-x,o::r-x" on /var/log/journal failed: Invalid argument
[...]
something went wrong, rolling back ...
HEAD is now at b759c8abc RUN.S apt-get update && apt-get upgrade -y
error: build failed: RUN command exited with 100
trace: build.py:1182:execute, build.py:251:__default__, visitors.py:241:_call_userfunc, visitors.py:269:visit_topdown, build.py:187:main, ch-image:304:main

I don’t see why anyone would want systemd in a container, but it's a dependency of many things and thus should probably work.

[reidpr]

The system call that fails is this:

setxattr("/proc/self/fd/4", "system.posix_acl_access", "\2\0\0\0\1\0\7\0\377\377\377\377\4\0\5\0\377\377\377\377\10\0\5\0\4\0\0\0\20\0\5", 44, 0) = -1 EINVAL (Invalid argument)

I believe the problem is that system attributes (or possibly a subset of them) cannot be written by unprivileged users.

setxattr(2) is pretty general, and I'm skeptical we should just disable it. Maybe we should add a --force=seccomp-aggressive that does?

[lucaudill]

In #1720 I had to add --force=none to the ch-image build calls in the difficult files test of 55_cache.bats. I did this because the dockerfile used for the build (difficult.df) includes a call to mkfifo(1), which fails silently because it calls mknod(2), which is a syscall that gets intercepted by our seccomp filter. If we're adding different levels of --force=seccomp, we should consider removing mknod(2) from the filter at lower levels.