charts/dagu/templates/coordinator-deployment.yaml (1)

27-31: ⚠️ Potential issue | 🟠 Major

Ensure /entrypoint.sh privilege-drop is compatible with the mounted /data PVC

Switching command: → args: preserves the image’s tini ENTRYPOINT, so Kubernetes now executes /entrypoint.sh:

args:
  - dagu
  - coordinator
  - --config
  - /etc/dagu/dagu.yaml

entrypoint.sh ends with:

• exec sudo ... -u "#${PUID}" -g "#${RUN_GID}" -- "$@"

The Helm chart sets no securityContext/runAsUser/fsGroup, and the image defaults PUID=${USER_UID} / PGID=${USER_GID} (both default to 1000; DOCKER_GID=-1 ⇒ RUN_GID=PGID). That changes the container from running as root (when command: bypassed the ENTRYPOINT) to running as 1000:1000.

Because the entrypoint only mkdir -p $DAGU_HOME (and the chart sets DAGU_HOME=/data) without chowning the mounted PVC, pre-existing /data permissions that were root-owned or otherwise not readable/writable by UID 1000 may break pods after this change.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@charts/dagu/templates/coordinator-deployment.yaml` around lines 27 - 31, The
container now runs the image ENTRYPOINT which drops privileges to PUID/PGID
(PUID/PGID → RUN_GID) and may be unable to write the mounted /data (DAGU_HOME);
add a compatible securityContext and/or an init step: set
pod.spec.containers[*].securityContext to runAsUser: <PUID> and fsGroup:
<RUN_GID> (make these values configurable via chart values), or add an
initContainer that runs as root to mkdir -p $DAGU_HOME and chown it to the same
UID/GID before the main container starts; reference the args block (switch to
ENTRYPOINT), entrypoint.sh privilege-drop, PUID, RUN_GID, PGID, and DAGU_HOME
when implementing the change.