fix: Containers - Bind Mounts - Security and Compatibility (Docker / Podman / SELinux) for Fetch, Git, and Time Servers

[trentapple]

The following includes patches to docker files for existing servers.

• fetch
• git
• time

Description

Unshared and private label limiting access to only the current container on bind mount files (Z) referenced by Dockerfile RUN. This allows the container to be used with a podman and SELinux configuration. Without it, the build fails due to the security system (SELinux) blocking attempts to use bind mounted content /app/pyproject.toml (and eventually /app/uv.lock).

Resources:

• https://developers.redhat.com/articles/2025/04/11/my-advice-selinux-container-labeling
• https://cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet.html#rule-6-use-linux-security-module-seccomp-apparmor-or-selinux
• https://docs.docker.com/engine/storage/bind-mounts/#configure-the-selinux-label

Server Details

• Server: fetch, git, time
• Changes to: Dockerfile

Motivation and Context

It improves compatibility / accessibility and enables security enhancements for hardened container environments.

Ultimately, the motivation is to allow using MCP servers with docker / podman on hosts that have SELinux container separation enabled and enforcing (default for podman). See also: rule 6 from OWASP security cheat sheet.

Additionally, one of the base images does not have the user / group “app” currently which is being used with a --chown that fails. This is secondary to the purpose of this PR, but app:app may need to exist in order for the build step to succeed in a fresh environment.

How Has This Been Tested?

Docker / Podman build on the Dockerfile in question. Then the built images were run as integrations for a customized LLM client / frontend.

Under src/fetch directory
podman build -t mcp/fetch .

Under src/time directory
podman build -t mcp/time .

Under src/git directory
podman build -t mcp/git .

The container build commands now succeed for docker / podman with security systems that are configured to handle containers.

Breaking Changes

No known / identified breaking changes.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Protocol Documentation
• My changes follows MCP security best practices
• I have updated the server's README accordingly
• I have tested this with an LLM client
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have documented all environment variables and configuration options

Additional context

LLM client test done with mcpo Dockerfile that is setup to include the artifacts from the built mcp/time. Then this was included as a full OpenAPI spec in tools for the local LLM client in use (see screenshot for end result).

For the missing user/group scenario, consider approach from DoD’s iron bank container for python312 which (at the time of writing this) explicitly creates a group / user with the ID (1001).

[trentapple]

These are the only three servers which needed an updated Dockerfile in order to work in secure environments.

[trentapple]

Relevant to missing app user/group in base image astral-sh/uv-docker-example/issues/29. Some environments may ignore (and without these changes it is possible to end up with root:root ownership), but the change is written to consistently succeed regardless.

I noticed @astral-sh currently do not use that --chown app:app in the Dockerfile, but it is in the standalone.Dockerfile and multistage.Dockerfile of uv-docker-example.

As it relates to SELinux and/or OWASP container guidance — there seems to be minimal risk with these changes and it enables greater accessibility / security in certain environments. Per the article by @rhatdan:

SELinux has blocked most of the container breakout scenarios from the past decade-plus

I noticed that ramalama took a comprehensive (more enterprise-friendly) approach to installing uv, but that may not be applicable here.

This is helpful in multiple scenarios, but YMMV.

[olaservo]

Thanks for this. The bind-mount and SELinux fixes for the fetch, git and time Dockerfiles are the kind of compatibility fix we want, and I'd like to get it in.

The branch has been conflicting with main for a while. If you can rebase, I'll review promptly. If I don't hear back in a couple of weeks I'll close this to keep the queue honest, and you're welcome to reopen or resubmit any time.

[olaservo]

I merged main into this branch and resolved it, with one change to the approach.

--mount=type=bind,...,Z is a buildah option. Docker's BuildKit rejects a bare key on a bind mount, so the branch as written failed on Docker:

$ docker build src/fetch          # Docker 27.4.0
ERROR: failed to solve: invalid field 'Z' must be a key=value pair

The merge commit replaces the two bind mounts with COPY uv.lock pyproject.toml ./ before the first uv sync. That removes the bind mount, so there is no SELinux label to set, and it works on both builders. Your useradd guard for the app user is kept as is. Verified docker build for fetch, git and time on this branch.

I do not have a podman/SELinux host to confirm the COPY form on. If you can re-run your podman build on the current head, that would be the last check before merging.

[Copilot]

🟢 Approval recommended

The focused changes consistently resolve the stated build compatibility and missing-user failures.

Pull request overview

Reworks Python server container builds for Podman/SELinux compatibility and ensures the app account exists before ownership assignment.

Changes:

• Replaces build-time bind mounts with copied dependency manifests.
• Creates the app system user and group when absent.

File summaries

File	Description
src/fetch/Dockerfile	Updates dependency staging and user creation.
src/git/Dockerfile	Updates dependency staging and user creation.
src/time/Dockerfile	Updates dependency staging and user creation.

Review details

• Files reviewed: 3/3 changed files
• Comments generated: 0
• Review effort level: Balanced

---

💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.