1.3 KiB
status, opened, located-in
| status | opened | located-in | ||
|---|---|---|---|---|
| open | 2026-09-22 |
|
081 — A cache consumer does not use the login it was granted
Symptom
Two catalogue modules require the cache and are given a login and a password under a keyspace of their own (issue 080), and neither tells its software the login: each hands it the host, the port and the password only, so the software authenticates as the server's default user and writes wherever it likes — or is refused, if the default user is closed. The grant is honoured by the provider and ignored by the consumer.
Found on review of issue 080, by reading the two manifests. Not run: no bed installs either module against the catalogue's cache and reads what it wrote.
Why it matters beyond the instance
A grant is two ends agreeing. The provider's end is checked by the grant bed; the consumer's end, that the software actually presents what it was given, is checked by nothing but the module working — and a module that works as the default user works.
What would close it
Each module passes the login it was bound (${bound:redis-cache:as}) to its software's username
setting, and a bed installs one of them against the catalogue's cache and reads back that its keys
sit under its login.