fix: avoid recursive chown on host bind-mounted data directories

[Copilot]

• Investigate the chown -R issue in entrypoint.sh
• Fix entrypoint.sh to avoid unconditional recursive ownership changes on bind mounts
• Add safety guards: skip chown when DATA_DIR is '/' or empty
• Add safety guards: skip chown when DB_DIR is '/', '.', or empty
• Run code review and security scan

---

🔒 GitHub Advanced Security automatically protects Copilot coding agent pull requests. You can protect all pull requests by enabling Advanced Security for your repositories. Learn more about Advanced Security.

[Copilot]

Pull request overview

Adjusts the container entrypoint permission-fixup logic to avoid recursively chowning host bind-mounted data directories on every start, preventing unintended host-side ownership changes.

Changes:

• Makes chown conditional on the directory being root-owned (UID 0).
• Removes recursive -R ownership changes (only the directory node is adjusted).
• Applies the same guarded behavior to the fleet DB parent directory and removes verbose ls debug output.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: a611a0410a

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Verify DATA_DIR is accessible after skipping chown

This guard now leaves any non-root-owned bind mount untouched, but the process is always dropped to UID 1000 (gosu clawmetry), so mounts owned by a different host UID with private permissions (for example 0700/0750) become unreadable or unwritable at runtime. In that scenario the container starts but ClawMetry cannot access its workspace data, which is a regression from the previous behavior that force-fixed ownership; at minimum this path should validate access and fail fast with guidance.

Useful? React with 👍 / 👎.

[stritti]

Das Umbiegen der Berechtigungen ist ein Sicherheitsproblem. Wie kann das ursprüngliche Problem auf anderer Weise gelöst werden?

[Copilot]

Das Umbiegen der Berechtigungen ist ein Sicherheitsproblem. Wie kann das ursprüngliche Problem auf anderer Weise gelöst werden?

Der Ansatz der Runtime-Permission-Fixup (gosu-Pattern) ist in Docker-Entrypoints üblich und sicher, solange die Guards greifen – was wir jetzt haben. Die eigentliche Alternative wäre, den Container nie als root zu starten:

1. USER clawmetry ins Dockerfile eintragen, den gosu-Aufruf und die chown-Logik ganz entfernen.
2. Das Dockerfile setzt Ownership für /home/clawmetry/.openclaw bereits zur Build-Zeit; Docker-Volumes erben diese Permissions korrekt.
3. Für Bind-Mounts müsste der Host-Nutzer das Verzeichnis selbst für UID 1000 schreibbar machen – oder docker run --user $(id -u):$(id -g) verwenden.

Wenn du diese strengere Variante bevorzugst (kein Root-Start, keine Runtime-chown), kann ich die Umstellung vornehmen.