llama.cpp rejects Apptainer tools support over host access risks

Maintainers of llama.cpp have rejected a proposed Apptainer runtime for the project's HTTP server tools endpoint, after finding it broke the existing container model and exposed the host filesystem to remote clients.

The server can run approved tools inside container runtimes such as Docker and Podman. The Apptainer path, as submitted, skipped the validation and running-container checks those runtimes use. Apptainer's default exec behavior also bind-mounts the real home directory of the user running the server under the same uid. A client calling the shell tool could therefore read private SSH keys from that home directory or delete its contents.

The same gap extended to image selection. Clients can name a runtime through a request header. With the Apptainer form, the server would pull and run whatever image the client supplied, including from remote registries. Existing Docker and Podman handling rejects anything that is not already a running, approved container.

Reviewers judged the change incompatible with the tools runtime design: nothing persisted between calls, and lifecycle handling did not match the other backends. A workable port would need Apptainer instances with the same start, exec, stop, and validation path as Docker and Podman, plus tests. As written, the feature was not accepted.