Repository navigation
Build fails with fs.read entitlement error when dockerfile is outside the build context (buildx >= 0.37.2) #14285
Description
Description
Since buildx v0.37.2 (GHSA-gwr2-q96m-6682), buildx bake --progress rawjson enforces filesystem entitlements instead of skipping the consent check. Compose always invokes bake that way, but localBuildPaths in pkg/compose/build_bake.go only grants --allow fs.read= for build.context and build.additional_contexts — not for build.dockerfile. A service whose Dockerfile lives outside its build context therefore no longer builds. Before buildx v0.37.2 the missing grant went unnoticed because the check was skipped under rawjson.
This breaks every Dev Container that uses a Compose service with build:: the devcontainer CLI writes Dockerfile-with-features into a temp directory and points dockerfile: at it through an override file (dockerCompose.ts), which fails with:
additional privileges requested: pass "--allow=fs.read=/private/var/folders/…/T/devcontainercli/container-features/0.76.0-…/Dockerfile-with-features" to grant requested privileges
The code is unchanged in v5.6.0 and on main.
Steps To Reproduce
mkdir -p /tmp/outside && echo 'FROM alpine' > /tmp/outside/Dockerfile
mkdir -p /tmp/repro && cd /tmp/repro
cat > compose.yaml <<'EOF'
services:
app:
build:
context: .
dockerfile: /tmp/outside/Dockerfile
EOF
docker compose build[+] Building 0.0s (1/1) FINISHED
=> [internal] load local bake definitions 0.0s
=> => reading from stdin 466B 0.0s
[+] build 0/1
⠋ Image repro-app Building 0.1s
additional privileges requested: pass "--allow=fs.read=../outside/Dockerfile" to grant requested privileges
Compose Version
Docker Compose version v5.5.1
Docker Environment
macOS (Apple Silicon), Docker Desktop 4.94.0 (241994), buildx v0.37.2
Anything else?
Workaround: BUILDX_BAKE_ENTITLEMENTS_FS=0, which disables the check for all paths.
Suggested fix: add the resolved Dockerfile path to the fs.read allowlist when it is a local path outside the context (dockerfile_inline is unaffected).
Activity
CI: Build the dev container without Compose's bake builder
simon360 commentedon Oct 7, 2026
The same thing applies for secrets that are outside of the working directory. For example, we have some
pippackages on a private repository in Google Cloud Artifact Registry, so at build time, we need the google cloud credentials. We do that with a secrets block in thedocker-compose.ymlfile:And then, in the
Dockerfile, we have this:This worked until the same change mentioned in the original submission came into play. Now, when we try to build, we get this error:
We've worked around it by adding:
under the
buildblock, which forces Compose to include~/.config/gcloudin thelocalBuildPaths, but this isn't ideal. It grants a larger scope than is necessary, since it's adding read-only permission for the wholegclouddirectory, when we only need the signle JSON file.marlonramirez commentedon Oct 7, 2026
Windows data point: I hit the same "additional privileges requested" failure on Windows 10 Pro 22H2 (Docker Desktop 4.94.0, Compose v5.5.1, buildx v0.37.2) in two situations.
VS Code Dev Containers (extension 0.469.0): the override points
dockerfile:atC:\Users\...\AppData\Local\Temp\devcontainercli\container-features\...\Dockerfile-with-features, outside the build context. This matches the issue. The real error only shows withdocker --debug compose --progress plain ... build; otherwise Compose prints justfailed to execute bake: exit status 1.Plain
docker compose -f d:\path\to\docker-compose.yml build, with the Dockerfile inside the context. With a lowercase drive letter it fails; withD:\it works. Debug output shows--allow fs.read=d:\...\.devcontainerwhile the Dockerfile is resolved asD:\...\Dockerfile, which is the path reported as missing.Reading the diff in #14286, the resolved Dockerfile path now gets its own grant, so case 2 should be covered too, as long as
dockerFilePathreturns the same string that is passed to bake asdockerfile. It may be worth adding a Windows test with a lowercase drive letter in the context path.BUILDX_BAKE_ENTITLEMENTS_FS=0works around both.rcollette commentedon Oct 8, 2026
We secret mount our JFrog credentials from our local maven settings at ~/.m2/settings.xml which is outside the project directory. This was an unexpected breaking change. Copilot CLI with Opus 5.5 even on autopilot does not want to use BUILDX_BAKE_ENTITLEMENTS_FS=0, without a user present, which is a major hang up for agentic development.
ci: allow bake fs reads in smoke jobs until Compose grants Dockerfiles
omer-hadari-cyera commentedon Oct 11, 2026
network.hostinbuild.entitlementsseems to not be passed to—alloweither which is also broken since this buildx version.thaJeztah commentedon Oct 11, 2026
cc @crazy-max
crazy-max commentedon Oct 12, 2026
This comes from the fix for GHSA-gwr2-q96m-6682 in Buildx v0.37.2. Compose invokes Bake with
--progress rawjson, which previously skipped entitlement enforcement, so the missing grants went unnoticed.GHSA-p54p-jq4x-rc28 was fixed in the same release but concerns implicit secret file sources and local OCI layout contexts. The secret examples above use explicit file sources, so those failures also come from enforcing the grants under
rawjson.Compose needs to pass the grants for the configured Dockerfile and secret paths, along with
--allow network.hostwhen requested. Setting the entitlement in the Bake target doesn't grant it, andBUILDX_BAKE_ENTITLEMENTS_FS=0won't help withnetwork.host.Seems #14286 covers the Dockerfile case, but we'll also need to address the secret and
network.hostcases reported here.focdanisch commentedon Oct 12, 2026
I guess that this issue might occur for
as well...
Build the digid-connector image with buildx bake
fix: grant compose bake read access to the combined Dockerfile (#252)
Wrap docker for Dev Containers so Compose builds survive buildx 0.37.2
Build the dev container from its own Dockerfile again