OpenClaw startup guard makes the managed CA bundle unreadable
- Dominant language
- TypeScript
- Stars
- 22.5k
- Forks
- 3.1k
- Avg merge
- 1d 1h
- Merged PRs (30d)
- 715
Description
## Investigation Summary
- Three managed onboarding and resume jobs create the CA bundle as root-owned mode `0444`, then fail to read it.
- `run_openclaw_config_guard --startup-owner` changes the shared parent `/run/nemoclaw` from mode `0755` to `0700`.
- The sandbox user cannot traverse the parent, so the readable bundle becomes inaccessible.
- Issue #8454 is related but distinct: its managed CA files are absent; this failure has present files with an unreadable parent.
- No existing issue matches this parent-permission failure.
## Description
Managed startup stores the merged CA bundle at `/run/nemoclaw/managed-startup-ca-bundle.pem`. The OpenClaw startup guard later uses the shared `/run/nemoclaw` directory for private guard output and changes that directory to mode `0700`.
Expected behavior: the shared runtime directory remains traversable, the CA bundle remains root-owned and read-only, and private guard state lives under a root-private child.
Actual behavior: CA validation fails with `Permission denied` even though the file mode is `0444`.
## Reproduction Steps
1. Onboard or resume managed OpenClaw with the corporate CA fixture.
2. Let the startup-owner configuration guard run.
3. Read `/run/nemoclaw/managed-startup-ca-bundle.pem` as the sandbox user.
4. Observe: `grep: /run/nemoclaw/managed-startup-ca-bundle.pem: Permission denied`.
## Environment
- Workflow: [unfiltered E2E run 32068537791](https://github.com/NVIDIA/NemoClaw/actions/runs/32068537791)
- Runner: GitHub-hosted Ubuntu
- Runtime: OpenShell Docker driver with managed OpenClaw
- Candidate commit: `eb560abae63f89183406b3cc273ecb8bf12ccfd2`
## Failure Evidence
- [Onboarding repair](https://github.com/NVIDIA/NemoClaw/actions/runs/32068537791/job/95506676783)
- [Onboarding resume](https://github.com/NVIDIA/NemoClaw/actions/runs/32068537791/job/95506676826)
- [Cloud onboarding](https://github.com/NVIDIA/NemoClaw/actions/runs/32068537791/job/95506674566)
## Acceptance Criteria
- `/run/nemoclaw` remains root-owned and traversable by the sandbox user.
- The managed CA bundle remains root-owned, read-only, and readable through its parent path.
- Startup-guard output remains in a root-private directory and is not readable by the sandbox user.
- Repair, resume, and cloud-onboarding CA checks pass in the complete unfiltered E2E run.
- The fix does not treat missing CA material as success.
## Relationship
Prerequisite for #9140. Related epic: #7744. Related but not duplicate: #8454.
Contributor guide
Research direction
Start by locating the implementation of run_openclaw_config_guard --startup-owner and the managed CA-bundle setup for /run/nemoclaw. Reproduce the permission failure with the corporate CA fixture, then run the repair, resume, and cloud-onboarding checks in unfiltered E2E. Done means the shared directory remains traversable, guard state is private, and the CA checks pass without accepting missing material.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker, typescript
- Domain
- infrastructure, security
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100