TokenManager was one flat map with no direction tag, written from both
sides of every relationship: the client stored the token it PRESENTS to a
callee under the CALLEE's name, and a token RECEIVED from a caller was
stored under the CALLER's name. Same namespace, last write wins.
This was documented as safe by topology — separate images keep the two
directions apart — and pending only for the shared-runtime migration. That
was wrong. It is live in the DEFAULT out-of-process configuration, and the
chain needs no attacker:
1. capability_module mints one token so M may call B.
2. It pushes it to B -> B's store gets ["M"] = T (inbound)
3. It returns it to M -> M's store gets ["B"] = T (outbound)
4. B then calls M. B's client looks in its OWN store for something to
present to M, finds T because step 2 put it there, and therefore SKIPS
requestModule entirely.
5. M authorizes T, having cached the identical value in step 3.
One grant M->B silently produces B->M, with no handshake, nothing logged,
and capability_module's access policy never consulted. Reproduced on the
pre-split tree, both halves red:
B's outbound lookup for M returned the token M was issued for calling B
Actual: false Expected: true
B authorized at M using the token minted for M -> B
Actual: true Expected: false
A second defect from the same cause: an inbound push CLOBBERS the outbound
cache under the same key, so M's next call to B goes out carrying B's own
inbound token, is rejected, and burns the single re-exchange recovering
from a collision it caused itself.
THREE ROLES, TWO MAPS AND A SCALAR:
m_outbound callee -> what I present when calling out
m_inbound caller -> what I issued to that caller
m_credential MY OWN host-issued credential
The anchor is what made a two-way split look impossible: it is genuinely
both directions, presented outbound to capability_module and compared
against inbound. But it is not a MAP. It is one value under two role labels
— "core" and "capability_module" — that collide with module names by
accident, and adoptCredential already wrote a single credential under every
bootstrap key. As a scalar it has no key namespace, so no reverse lookup
can produce a name from it. A key living in both maps would have been a
rename, not a split.
The hoped-for cheap route did not exist: logos_module_accept_token forwards
to lp_token_save in BOTH backends, and the Qt glue calls that one export
for an inbound caller token in one place and the module's own anchor in
another. The doors were never divided, so this could not be done by routing
two existing C ABI doors to two maps — but it needs no new door either.
Four detector tests red before, green after. Constant time survives at the
instruction level and the comparison count stays input-independent.
KNOWN GAP, deliberately not fixed here: the generated glue writes the same
inbound token through BOTH doors (lidl_gen_cdylib_glue.cpp:371-380). Safe
only while module cdylibs are separate images — which is exactly what the
shared-runtime migration collapses. Closing it means a dedicated inbound
export on the module-impl C ABI: a MINOR bump plus a definition in both
backends in the same wave. Price it before that migration lands, not after.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Five tests, four red on unmodified c698402 (513 tests, 509 pass). No
production edit — the reds are shipped behaviour.
The headline is not the single-image future. It is that one grant M->B
already produces B->M today, in the default topology, with no handshake and
capability_module's access policy never consulted:
capability mints one value; it is pushed to B (B's store, keyed "M") and
returned to M (M's store, keyed "B"). B's client reads its OWN store for
something to present to M (logos_api_client.cpp:124), finds that value
because informModuleToken wrote it to the same object the client reads
(logos-plugin-qt logos_api.cpp:53 / logos_provider_object.cpp:46), and so
skips requestModule. M accepts it, because M cached the identical value
outbound and ModuleProxy::authorize scans that store whole
(module_proxy.cpp:419-424).
Every module process is single-image for this purpose — outbound
(logos_api_client.cpp:201), inbound (logos_provider_object.cpp:53) and the
anchor (module_initializer.cpp:169-170) all land in one QHash there.
Also red: an inbound push CLOBBERS the outbound per-target cache under the
same key, so the next call out carries the peer's own inbound token and burns
the one re-exchange recovering from a self-inflicted collision.
Note test_call_caller.cpp:231 asserts the OPPOSITE of test 422 on purpose —
it pins that an outbound token still authorizes. That assertion is the line
this moves, and it has to flip in the same commit as the fix.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
