Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

postCreateCommand fails with EACCES using Docker Engine on an SELinux enforcing system #914

Open
strugee opened this issue Oct 7, 2024 · 0 comments

Comments

@strugee
Copy link

strugee commented Oct 7, 2024

Basically, what the title says. See also #548; it appears that this bug is caused because the fix there was incomplete. In particular, having skimmed that issue to get a vague, possibly-incorrect understanding that the fix was to detect if the build phase was occurring under Buildah, I see two problems with this:

  • Buildah (and Podman) can be run on non-SELinux systems, where this SELinux handling is not necessary (though AFAIK, it's a noop, so making it apply unconditionally is an option for a fix)
  • SELinux restrictions are also hitting other, non-build phases - in my case, the postCreateCommand specified in devcontainer.json.

STR (these aren't my exact STR since I'm simplifying out Silverblue-related environmental setup that I'm confident doesn't matter - but if you somehow can't reproduce, I can provide more specific STR)

  1. Install Fedora
  2. Install Node from somewhere
  3. npm install -g @devcontainers/cli
  4. Clone home-assistant/core@4721f8e and cd into it
  5. devcontainer up --workspace-folder .

Expected result: the command succeeds.

Actual result:

[lots of irrelevant output]
Step 10/10 : USER $IMAGE_USER
 ---> Using cache
 ---> 3876e42a0eba
Successfully built 3876e42a0eba
Successfully tagged vsc-core-6cd99f764fb93154741da6b8ffb75e0d12d5e8fa5728b883b20a277436d294a0-uid:latest
[4768 ms] Start: Run: docker run --sig-proxy=false -a STDOUT -a STDERR -p 8123:8123 -p 5683:5683/udp --mount type=bind,source=/var/home/alex/Development/core,target=/workspaces/core -l devcontainer.local_folder=/var/home/alex/Development/core -l devcontainer.config_file=/var/home/alex/Development/core/.devcontainer/devcontainer.json -e PYTHONASYNCIODEBUG=1 -e GIT_EDITOR=code --wait --entrypoint /bin/sh vsc-core-6cd99f764fb93154741da6b8ffb75e0d12d5e8fa5728b883b20a277436d294a0-uid -c echo Container started
Container started
Running the postCreateCommand from devcontainer.json...

/bin/sh: 1: script/setup: Permission denied
[7214 ms] postCreateCommand failed with exit code 126. Skipping any further user-provided commands.
Error: Command failed: /bin/sh -c script/setup
    at G7 (/var/home/alex/.local/lib/node_modules/@devcontainers/cli/dist/spec-node/devContainersSpecCLI.js:235:130)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async tm (/var/home/alex/.local/lib/node_modules/@devcontainers/cli/dist/spec-node/devContainersSpecCLI.js:227:4483)
    at async $w (/var/home/alex/.local/lib/node_modules/@devcontainers/cli/dist/spec-node/devContainersSpecCLI.js:227:3828)
    at async em (/var/home/alex/.local/lib/node_modules/@devcontainers/cli/dist/spec-node/devContainersSpecCLI.js:227:3032)
    at async pa (/var/home/alex/.local/lib/node_modules/@devcontainers/cli/dist/spec-node/devContainersSpecCLI.js:227:2438)
    at async FtA (/var/home/alex/.local/lib/node_modules/@devcontainers/cli/dist/spec-node/devContainersSpecCLI.js:465:1534)
    at async bH (/var/home/alex/.local/lib/node_modules/@devcontainers/cli/dist/spec-node/devContainersSpecCLI.js:465:964)
    at async TtA (/var/home/alex/.local/lib/node_modules/@devcontainers/cli/dist/spec-node/devContainersSpecCLI.js:482:3848)
    at async iB (/var/home/alex/.local/lib/node_modules/@devcontainers/cli/dist/spec-node/devContainersSpecCLI.js:482:4963)
{"outcome":"error","message":"Command failed: /bin/sh -c script/setup","description":"The postCreateCommand in the devcontainer.json failed.","containerId":"436ea8eaa4dfec5e42c5011ea09cbc45b7f980d8922054c7e93e1ce70cf6bc38"}

Environment info:

% docker --version
Docker version 24.0.5, build %{shortcommit_cli}

% devcontainer --version
0.71.0

% node --version
v20.12.2

% cat /etc/os-release # This is talking about a container image because I'm using Fedora Silverblue and running these commands inside a https://containertoolbx.org/ container - but Docker is running on the host; see below
NAME="Fedora Linux"
VERSION="39 (Container Image)"
ID=fedora
VERSION_ID=39
VERSION_CODENAME=""
PLATFORM_ID="platform:f39"
PRETTY_NAME="Fedora Linux 39 (Container Image)"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:39"
DEFAULT_HOSTNAME="fedora"
HOME_URL="https://fedoraproject.org/"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f39/system-administrators-guide/"
SUPPORT_URL="https://ask.fedoraproject.org/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=39
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=39
SUPPORT_END=2024-11-12
VARIANT="Container Image"
VARIANT_ID=container

% type docker
docker is /var/home/alex/bin/docker

% cat ~/bin/docker # Basically, this script detects whether it's being run inside a toolbx container, and if it is, it runs the real command on the host instead of the container, to circumvent container-inside-container issues
#!/bin/sh

BINARY=$(basename $0)

CMDPREFIX=
test -f /run/.toolboxenv && CMDPREFIX='flatpak-spawn --host'

# Can't use `command` because this is a script, not a function/alias.
# This is evil because it breaks with paths including newlines, but those paths are evil anyway.
exec $CMDPREFIX $($CMDPREFIX which -a $BINARY | grep -Fve '~/bin/' -e ~/bin/ | head -1) "$@"

% flatpak-spawn --host getenforce # flatpak-spawn because getenforce doesn't exist inside the toolbx container image
Enforcing
strugee added a commit to strugee/core that referenced this issue Oct 7, 2024
On SELinux-enforcing systems, such as stock Fedora (to be more precise,
in my case, Fedora Silverblue), running `scripts/setup` fails with a
"Permission Denied" error. Fixing the root cause here seemingly
requires mucking around in the devcontainers CLI source, so we just
bail out and use a workaround.

Upstream bug: devcontainers/cli#914
strugee added a commit to strugee/core that referenced this issue Oct 7, 2024
On SELinux-enforcing systems, such as stock Fedora (to be more precise,
in my case, Fedora Silverblue), running `scripts/setup` fails with a
"Permission Denied" error. Fixing the root cause here seemingly
requires mucking around in the devcontainers CLI source, so we just
bail out and use a workaround.

Upstream bug: devcontainers/cli#914
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant