compat: confine dockerfile to build context

[1seal]

this fixes the compat build handler's dockerfile query parameter resolution to ensure the resolved path cannot escape the extracted build context directory.

• rejects ../ traversal escapes
• rejects absolute paths outside ContextDirectory (still allows absolute paths within the context for libpod/local build semantics)
• adds a linux-only unit test for confinement checks

this is being filed as a bug/hardening change (not a security issue) per maintainer guidance on the podman system service threat model.

[Luap99]

I have not made a careful look on what is going but this is breaking many tests depending on the current behavior, seems like there are many tests checking that we can use dockerfiles outside of the context dir so I am not sure we can or should switch that as it could break many users.

[1seal]

thanks for the review.

i agree this is an API change and will break any callers/tests that relied on the compat handler reading a dockerfile outside the provided build context.

the motivation for the change is twofold:

• correctness/compat: the compat build docs describe dockerfile as a “path within the build context”, but the current handler allows ../ escapes and absolute paths to become host filesystem paths.
• hardening: confining dockerfile to the extracted context removes a surprising host-path read behavior from the API surface.

to reduce user impact, i think the right direction is:

• keep local build semantics unchanged (where podman build -f /abs/path may be valid for local workflows).
• for the docker-compat POST /build handler, treat dockerfile as context-relative only and reject values that resolve outside ContextDirectory.

if we have tests asserting “dockerfile outside context works”, i suggest updating them to build a context that includes the intended dockerfile (client-side), then pass a context-relative path.

this pr already allows absolute paths that still resolve within ContextDirectory, and rejects traversal/absolute paths that escape.

[giuseppe]

I don't see why we need this limitation, there is nothing harmful in a Dockerfile outside of the build context

[1seal]

thanks.

i’m not trying to introduce a new security boundary here (agree with the system service threat model).

the main reasons for confining dockerfile in the compat POST /build handler are correctness/compat and reducing surprising host-fs reads:

• the compat API docs describe dockerfile as a path within the build context, but today ../ and some absolute paths can be interpreted as host filesystem paths outside the extracted context.
• docker remote build semantics assume the daemon only reads inputs from the provided context (the client is responsible for adding a dockerfile that lives elsewhere into the context tar).
• allowing the server to reach outside the context makes remote builds less reproducible and harder for API clients to reason about.

local podman build -f /abs/path workflows remain valid; this change is limited to the docker-compat service handler. #28072 also still permits absolute paths that resolve within ContextDirectory.

[1seal]

pushed an update to address the ci failures caused by the stricter dockerfile confinement.

changes in this commit:

• server: apply the dockerfile confinement checks only for the docker-compat POST /build handler (non-libpod). keep libpod local build semantics (absolute dockerfile paths can be outside the context), which fixes the apiv2 expectation for a 404 on a missing dockerfile path.
• client (bindings): for remote POST /build, ensure any dockerfile outside the context (including -f - stdin) is copied into the context directory and the dockerfile query param is set to a context-relative path. this keeps remote builds working for -f -, -f /abs/path, and -f ../Dockerfile-style cases without requiring the service to read host paths.
• windows/remote-tag unit tests: add a minimal remote stub file for pkg/api/handlers/compat so test runners that enable the remote build tag don’t fail with “build constraints exclude all Go files”.

hopefully this unblocks the remote/system build tests that were previously relying on absolute host dockerfile paths.

[1seal]

pushed a dco-signed amend for the latest commit (no functional changes).

[1seal]

follow-up: tightened server-side scoping so confinement applies to /build and /libpod/build, while /libpod/local/build keeps host-path dockerfile semantics.

[packit-as-a-service]

tmt tests failed for commit 3ee8bdb. @lsm5, @psss, @thrix please check.

[1seal]

thanks.

fyi that packit/tmt failure was for an earlier commit (3ee8bdb). current pr head is ee0734a95 and packit testing-farm jobs for it are already running.

once those finish, happy to take another look if anything is still failing.

[packit-as-a-service]

tmt tests failed for commit ee0734a. @lsm5, @psss, @thrix please check.

[1seal]

minor follow-up: fixed the linux unit test to use a path-only request target (previously used an absolute URL, which caused IsLibpodRequest() to misclassify libpod endpoints in the test). current head includes 44e24ef14.

[packit-as-a-service]

tmt tests failed for commit 44e24ef. @lsm5, @psss, @thrix please check.

[jankaluza]

I checked the code and it looks OK, but I cannot judge if the feature makes a sense in general. That's up to others :-).

[thrix]

/packit retest-failed

[github-actions]

A friendly reminder that this PR had no activity for 30 days.

[1seal]

stale bot pinged this, so a brief follow-up.

current head narrows the server-side confinement to the remote build handlers (/build and /libpod/build) while keeping /libpod/local/build host-path semantics intact, and the bindings side copies out-of-context dockerfiles into the context for remote builds. the goal is to avoid surprising host-fs reads on the remote API surface without changing local build workflows.

if maintainers prefer a different shape here, i can split this further, adjust tests again, or close it. otherwise, is there a preferred next step or decision on whether this hardening/compat change should move forward?