mirror of
https://code.fcc.sh/fireclover/public-cloudless-charts.git
synced 2026-08-08 08:55:07 +00:00
No description
- Go Template 63.3%
- Shell 36.7%
| Filename | Latest commit message | Latest commit date |
|---|---|---|
a074c9a6b4
The chart documented "Revocation does NOT drop the role - VALID UNTIL handles expiry" but never set revocation_statements, so OpenBao fell back to its built-in default, which does DROP ROLE. That fails permanently with SQLSTATE 2BP01 because the role still holds the two GRANTs from creation_statements, so every lease retried on exponential backoff forever and leases leaked. Two changes: 1. revocation_statements="SELECT 1;" - an explicit no-op, which is what the overlap design actually wants. Dropping at DEFAULT_TTL (24h) would kill credentials still valid until VALID UNTIL (36h) and break the 12h window. 2. The creation_statements cleanup loop now REVOKEs both grants before DROP ROLE. Previously DROP ROLE alone hit the same 2BP01 and the loop's "EXCEPTION WHEN others THEN NULL" swallowed it, so expired roles accumulated instead of being reaped. DROP OWNED BY is deliberately not used: PGUSER is not a member of the v-% roles and gets "permission denied to drop objects". Verified on a live tenant that the roles own no objects (pg_shdepend deptype='a' only, 2 ACL entries each), so revoking the two grants is sufficient and cannot lose data. Verified against huh-icehockey-gate in a rolled-back transaction as the unprivileged app user: 5 dynamic roles -> 3, both expired ones reaped. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
| .forgejo/workflows | ||
| charts | ||
| docs/superpowers/specs | ||
| README.md | ||