[jwvanderstam]

What

QP-9 review finding R-11 (Low): the image's source was owned by the runtime user. The virtual environment was too. So code execution in the app could persist by rewriting a module, or by dropping a new one into /app (first on sys.path) that shadows any import.

Change

• Dockerfile:
  • The source and /opt/venv are copied without --chown, so root owns them.
  • USER 0:0 at the start of the runtime stage. The hardened base already runs as 65532, and WORKDIR creates its directory as the current user, so without this /app itself stayed writable. I found that by building the image and checking; it is the second commit.
  • The runtime user writes only /app/logs, /app/uploads and a new /app/data.
  • The image sets STATE_FILE=/app/data/app_state.json and RERANKER_MODEL_PATH=/app/data/reranker/latest.
• src/config.py: STATE_FILE is read from the environment. The default stays app_state.json, so host runs are unchanged.
• src/rag/feedback_pipeline.py: a fine-tune writes its versions beside RERANKER_MODEL_PATH, where promote_model's latest.txt pointer and the reranker look. Before, it wrote to a fixed ./models/reranker, which is no longer writable in the image.
• docker-compose.yml: a new app_data volume on /app/data. A fresh volume is seeded from the image, owned by 65532, so no upgrade chown is needed.
• docker-smoke: a new step asserts write access in the built image: /app, /app/src, a module and /opt/venv/lib read-only; logs, uploads and data writable.

Behaviour change (CHANGELOG, Changed)

The active model and RAG parameters now survive a container recreation. They were lost on every up -d --build (ROADMAP's accepted-debt entry). When upgrading, values held in the old container are not carried over and must be set once more. A fine-tuned reranker in the old container falls back to the base model until retrained. The ROADMAP entry's real fix, an app_settings table, still stands for coherence; its Docker bullet is annotated.

Verification

• Built locally as localchat:r11-smoke (the live stack untouched):
  • uid 65532;
  • the write-access matrix exactly as asserted, with nothing wrong;
  • src.config imports with production variables, and set_active_model writes /app/data/app_state.json.
• Unit: a fine-tune without output_dir writes beside RERANKER_MODEL_PATH and points latest.txt at it. The config-doc, env-example and compose tests pass, and ruff is clean.
• The docker-smoke boot and security-smoke (full compose) will exercise the rest in CI.

🤖 Generated with Claude Code

https://claude.ai/code/session_01KkWPqAcWbxfqz1aCP6Qsdx

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota. Try requesting a review at a lower effort level.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota. Try requesting a review at a lower effort level.

[jwvanderstam]

Separate security review (CONTRIBUTING / QP-9)

A separate agent session reviewed this PR. It built the image under a throwaway tag and walked the filesystem as uid 65532. No finding at Medium or above.

• Writable for 65532: /app/data, /app/logs, /app/uploads, plus the base's HOME, /tmp, /var/tmp and /var/lock.
• None of those is on sys.path. PYTHONPATH is unset, and ENABLE_USER_SITE is False, so a planted .pth/usercustomize under HOME never loads.
• A fresh app_data volume is seeded with uid 65532.
• Every runtime write (uploads, logs, /tmp, the state file's tmp-then-rename, fine-tune output) still lands somewhere writable.

Findings and answers:

Finding	Answer
Low: the reranker loaded whatever latest.txt or a version row named, so code execution could persist a tampered model on the app_data volume. Weights only under the pinned transformers/torch defaults.	Fixed in the follow-up commit. confined_model_path loads a pointed or promoted model only if it lies beside RERANKER_MODEL_PATH, and every CrossEncoder gets trust_remote_code=False explicitly. tests/unit/test_reranker_model_is_confined.py.
Low: promoting or rolling back to a version trained into ./models before the upgrade activated the row, then failed to write the pointer, leaving the database and the running model out of step.	Fixed: the version's model must exist inside the model directory, and the pointer is written before the row is activated. The CHANGELOG upgrade note says so.
Low: the smoke assertion sampled seven paths.	Fixed: it walks /app and /opt/venv, and fails on anything writable outside logs/uploads/data, on anything writable on sys.path, and on user site. Verified locally against a fresh build (no problems).
Info: STATE_FILE/RERANKER_MODEL_PATH are operator-set; pointing them off the volume degrades, it does not crash.	Accepted.
Info: DEPLOYMENT.md still said "both paths".	Fixed: logs and uploads are the volumes that may predate the hardened image; app_data is always fresh.
Info: settings in the old container are lost on upgrade, no worse than any recreation before.	Agreed; a minor release fits.

🤖 Generated with Claude Code

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota. Try requesting a review at a lower effort level.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota. Try requesting a review at a lower effort level.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota. Try requesting a review at a lower effort level.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota. Try requesting a review at a lower effort level.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota. Try requesting a review at a lower effort level.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
93.5% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud