1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
//! Minimal authorization seam for privileged operations (issue #1714).
//!
//! Why: `palace_create force=true` bypasses the project-slug validation gate
//! (see `tools::palace_ops::handle_palace_create` and
//! `service::core::MemoryService::create_palace`) with NO authorization check
//! today — any caller that can reach either surface can create/overwrite a
//! palace under an arbitrary slug. That is an accepted trade-off for the
//! current single-tenant / local deployment model, which is the only mode
//! this daemon ships in today. The spec envisions a future multi-tenant
//! chat-session-storage mode where a low-privilege tenant could otherwise
//! clobber another tenant's palace by colliding a slug. Building a real
//! multi-tenant auth system (caller identity, per-tenant capability grants, a
//! slug-ownership table) is explicitly out of scope for this fix — the PM
//! decision here is: preserve today's single-tenant behaviour unchanged (no
//! existing caller breaks) while adding the narrowest possible seam a future
//! auth layer can hook into without touching either `force`-bypass call site
//! again.
//! What: `AppState::multi_tenant_mode` (default `false`; opt-in via
//! `TRUSTY_MEMORY_MULTI_TENANT=1` through
//! `AppState::with_multi_tenant_mode_from_env`) gates the single check in
//! this module, [`authorize_force_palace_create`]. In single-tenant mode
//! (the default, unchanged from before this fix) the check is a no-op — every
//! existing caller keeps working exactly as before. Multi-tenant mode has no
//! capability model to consult yet, so it fails CLOSED: `force=true` is
//! refused outright rather than silently honoured.
//! TODO(#1714 follow-up): replace the fail-closed placeholder with a real
//! capability check once caller identity is threaded through MCP / HTTP
//! requests (e.g. a signed header verified against a tenant->slug ownership
//! table). Until then, multi-tenant mode intentionally cannot use `force` at
//! all.
//! Test: `authorize_force_palace_create_allows_single_tenant_default`,
//! `authorize_force_palace_create_denies_multi_tenant_without_capability` in
//! `lib_tests`.
use crateAppState;
use ;
/// Gate `palace_create force=true` behind an explicit authorization signal.
///
/// Why/What: see module docs.
/// Test: see module docs.