makearmy/le-app
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

correct contained Codex runtime plan

Browse source
This commit is contained in:
makearmy 2026-07-12 15:02:29 -04:00
parent 0e3d5ea5ca
commit 13ec935e87
3 changed files with 275 additions and 512 deletions
Download patch file Download diff file Expand all files Collapse all files

25
docs/le-app-database-migration/environment-parity.md
View file

@ -140,29 +140,34 @@ Local HTTPS is required to test secure cookies. A repository-controlled developm
## Rootless Codex-controlled runtime
Required target: a dedicated rootless Docker daemon owned by the separate `le_app_codex` account. Future Codex migration sessions must execute as that account (preferred) or through a narrowly scoped account transition; the daemon socket is not shared broadly. Rootless Podman is an acceptable fallback only after Compose/profile behavior is proven; Docker is preferred because the repository and production already use Compose.
Required target: a genuine per-user rootless Docker service owned by `le_app_codex` and managed through the explicitly root-started `user@1200.service`. Root applies the filesystem, network-namespace, device, and resource boundary to the complete user manager so Codex, RootlessKit, Docker, and containers inherit it. The only accepted endpoint is `unix:///run/user/1200/docker.sock`; the daemon socket is not shared broadly. A system service running `dockerd` with `User=le_app_codex` is prohibited.
Codex must be able to build images, create/remove only its project containers/networks/volumes, inspect their logs, reset disposable PostgreSQL, run finite jobs, and execute integration/browser tests. It must not access `/var/run/docker.sock`, the production daemon/context, production containers/volumes/networks, `/var/www`, or `/srv/directus-archive`.
Current host observation:
Current host observation and planning checkpoint:
- `sol6_vi` is not in the Docker group but can read the production application's world-readable environment files under `/var/www`;
- Docker and Docker Compose clients exist;
- no Podman client is installed;
- the default Docker context does not provide a usable daemon/security result to this user;
- no enabled user-level rootless Docker or Podman service was detected.
- no enabled user-level rootless Docker service was detected;
- no persistent `le-app-codex` namespace or project nftables policy is deployed;
- approved DNS remains unresolved; the host resolver currently includes `192.168.10.1`, which is an observation rather than approval;
- numerous existing Docker IPv4 and IPv6 bridge ranges must be dynamically inventoried and denied rather than represented only by a stale list.
Therefore a `sol6_vi`-owned daemon is rejected: it could bind-mount those readable production secrets. Milestone 0 requires the isolated account and host changes described in `host-runtime-plan.md`, and work must stop before performing them. An administrator must approve/provision:
1. dedicated `le_app_codex` identity and restricted filesystem ACLs;
2. rootless prerequisites (`newuidmap`/`newgidmap`, subordinate UID/GID ranges, rootless networking and overlay helpers as required by the OS);
3. rootless Docker daemon installation for `le_app_codex` using its dedicated data root and named context;
4. optional user-service lingering if stacks must survive logout;
5. deterministic CPU BGBye first; optional GPU access only after core acceptance;
6. user/browser-profile-scoped development CA trust;
7. capacity limits for images, caches, snapshots, media, PostgreSQL, and test artifacts.
2. an explicitly selected package path: scheduled full host maintenance or a clean-chroot/current-system-compatible investigation, never a partial Arch upgrade;
3. a checksum-pinned Moby rootless launcher matched to the installed Docker release, not the unmodified AUR extras package or its global sysctl hook;
4. instance-specific containment on `user@1200.service`, the proposed `user-1200.slice` resource limits, and no lingering;
5. a root-created IPv4-only namespace with default-deny egress and dynamic denial of host, LAN, WireGuard, metadata, private, loopback, Docker bridge, SMTP, and IPv6 access;
6. inert acceptance tests before starting the user manager, Docker, or Codex;
7. deterministic CPU BGBye first; optional GPU access only after core acceptance;
8. user/browser-profile-scoped development CA trust;
9. a separately approved disk-growth limit for images, caches, snapshots, media, PostgreSQL, and test artifacts.
No production socket forwarding, Docker-group membership, broad sudo rule, daemon TCP exposure, or bind mount into production paths is acceptable.
Lingering must remain disabled. No production socket forwarding, Docker-group membership, broad sudo rule, daemon TCP exposure, system-service `dockerd`, or bind mount into production paths is acceptable. See `host-runtime-plan.md` for the approval-gated lifecycle and unresolved DNS, address-inventory, authentication, package, and disk-quota decisions.
## One-command workflows