RUN --mount=type=bind scripts are not executable when podman remote API daemon stages build context on a noexec filesystem

[ide-developer]

Issue Description

When using podman build through the remote API socket (CONTAINER_HOST), the client tarballs the build context and sends it to the daemon. The daemon extracts it to a temporary directory (typically /var/tmp). If that filesystem is mounted with noexec, the noexec flag propagates through RUN --mount=type=bind into the container, making bind-mounted scripts non-executable.

The same build succeeds with direct sudo podman build (no socket), because the build context is accessed in-place from the host filesystem.

Steps to reproduce the issue

# 1. Mount /var/tmp as noexec
export TMPDIR=/tmp/test-noexec
mkdir -p "$TMPDIR"
sudo mount --bind -o rw,noexec,nosuid,nodev,bind "$TMPDIR" /var/tmp

# 2. Create a build context with an executable script
mkdir -p /tmp/test-ctx/utils
cat > /tmp/test-ctx/utils/helper.sh <<'SH'
#!/bin/bash
echo "helper ran successfully"
SH
chmod 755 /tmp/test-ctx/utils/helper.sh

cat > /tmp/test-ctx/Dockerfile <<'DF'
FROM registry.access.redhat.com/ubi9/ubi-minimal:latest
USER 0
RUN --mount=type=bind,source=utils/helper.sh,target=/helper.sh,ro \
    /helper.sh
DF

# 3. Direct build works
sudo podman build --security-opt label=disable --no-cache -t test-direct /tmp/test-ctx
# → PASS: "helper ran successfully"

# 4. Remote API build fails
sudo systemctl start podman.socket
CONTAINER_HOST=unix:///run/podman/podman.sock \
  podman --remote build --security-opt label=disable --no-cache -t test-remote /tmp/test-ctx
# → FAIL: /bin/sh: line 1: /helper.sh: Permission denied

# Cleanup
sudo umount /var/tmp
rm -rf "$TMPDIR" /tmp/test-ctx

Describe the results you received

STEP 3/3: RUN --mount=type=bind,source=utils/helper.sh,target=/helper.sh,ro     /helper.sh
/bin/sh: line 1: /helper.sh: Permission denied
Error: building at STEP "RUN --mount=type=bind,source=utils/helper.sh,target=/helper.sh,ro /helper.sh": while running runtime: exit status 126

Describe the results you expected

The build should succeed. The noexec mount flag on the daemon's staging directory should not propagate through RUN --mount=type=bind into the build container, since the Dockerfile author expects bind-mounted files to be executable based on their file permissions.

Direct sudo podman build (without the socket) succeeds because the build context is accessed in-place and the source file is on a normal (exec-allowed) filesystem.

podman info output

$ podman --version
podman version 5.8.2

$ uname -r
6.14.7-200.fc44.x86_64

Also reproduced on GitHub Actions ubuntu-24.04 runners with Podman 5.5.0 installed via Homebrew (Linuxbrew), running as a rootful systemd service.

Podman in a container

No

Privileged Or Rootless

Rootful

Upstream Latest Release

Yes

Additional environment details

The scenario arises naturally in CI environments where:

1. /var/tmp is mounted noexec for security hardening (or to redirect podman's temp I/O to a different volume)
2. podman build is invoked through the remote API socket (CONTAINER_HOST)
3. Dockerfiles use RUN --mount=type=bind to bind-mount helper scripts from the build context

The root cause is that the remote API client tarballs the build context, the daemon extracts it to its temp directory (/var/tmp by default), and the noexec mount flag on that filesystem is inherited by the bind mount inside the container.

Additional information

Workarounds:

• Use direct podman build instead of the remote API
• Ensure the daemon's temp directory is not on a noexec filesystem
• Replace RUN --mount=type=bind with COPY + RUN + cleanup
• Use bash /path/to/script.sh instead of direct execution /path/to/script.sh

Possible fix: The daemon could either:

• Strip noexec from bind mounts created by RUN --mount=type=bind during builds
• Stage the extracted build context on a filesystem without noexec
• Detect and warn when the staging directory has noexec

[ide-developer]

Related: #20839 — same class of issue where the podman remote daemon ignores TMPDIR and hardcodes /var/tmp for temporary files. That issue reports it for container image pulls; this one is for build context extraction during podman build via the API.