fix(docker): keep root runtime to avoid bind-mount permission denied

[dingyufei615]

Motivation

• Running the final process as appuser caused host bind-mounted directories (e.g. prompts/, jsonl/, logs/, images/) to be unreadable/writable due to UID/GID mismatches, producing [Errno 13] Permission denied at runtime.

Description

• Replace USER appuser with USER root in Dockerfile and add comments explaining the bind-mount UID/GID issue and recommending deployment-side UID/GID handling or an entrypoint chown if non-root execution is required.

Testing

• No automated tests were executed in this environment; VCS operations (git diff, git commit) completed successfully and CI/pytest should be run after this change is pushed for full validation.

---

Codex Task

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses critical permission issues encountered when Docker containers attempted to access host bind-mounted directories. By reverting the Docker user from appuser to root, it ensures that the application can read and write to these volumes without Errno 13: Permission denied errors, improving out-of-the-box usability and maintaining compatibility with existing deployment patterns. This change prioritizes functionality for common bind-mount scenarios while offering clear instructions for more secure, non-root configurations.

Highlights

• Permission Fix: The Dockerfile was updated to run the container's main process as root instead of appuser to resolve [Errno 13] Permission denied errors when accessing host bind-mounted directories.
• Dockerfile Documentation: Detailed comments were added to the Dockerfile explaining the UID/GID mismatch problem with bind mounts and providing guidance for scenarios where non-root execution is desired, suggesting deployment-side UID/GID handling.

Changelog

• Dockerfile
  • Switched the USER directive from appuser to root to prevent permission errors with bind-mounted volumes.
  • Added extensive comments in Chinese explaining the rationale behind running as root due to bind-mount permission issues and suggesting solutions for non-root environments.

Activity

• No specific activity (comments, reviews, or progress updates) has been recorded for this pull request yet.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This PR aims to resolve Docker bind-mount permission issues by changing the container's runtime user from appuser to root. However, running the container as root introduces a significant security risk by violating the principle of least privilege. While this approach addresses the functional requirement, it is not a security best practice. It is strongly recommended to adopt a more secure alternative, such as using an entrypoint script to adjust directory permissions at container startup and then switching to a non-root user to run the application. This ensures the application runs with the minimum necessary privileges without sacrificing security.

[gemini-code-assist]

The container is configured to run as the root user, which significantly increases the risk and impact of a container escape or application compromise by violating the Principle of Least Privilege. While this change aims to resolve bind-mount permission issues, running applications as root in a container is a severe security risk. If an attacker gains code execution, they would have full root access. A more secure approach is to maintain the appuser and use an entrypoint script. This script would run as root initially to chown the necessary bind-mounted directories to appuser, and then use a tool like su-exec or gosu to switch to appuser before executing the main application command. This ensures that the application runs with minimal privileges, with root only used for the brief permission adjustment.

USER appuser