fix(sharing): `publicSharing.eligibility` is declared-but-unenforced — a draft or internal record mints a `public` share link and is served anonymously

[huangyiirene]

Found while implementing share-link publishing in the HotCRM app (objectstack-ai/hotcrm#601, PR objectstack-ai/hotcrm#1103). Not fixable from that side, and the app deliberately shipped without the feature rather than declare a key that does nothing — the measurement is below.

Same class as #3865 (full access level declared Transfer/Share/Delete and was equivalent to edit), and #3865's resolution — remove the option rather than let it mislead — is one of the two routes here.

The key

packages/spec/src/data/object.zod.ts, inside publicSharing:

eligibility: z.string().optional()
 .describe('CEL expression that must evaluate to true on the target record'),

with the TSDoc above it:

Optional CEL/JSONLogic predicate evaluated against the candidate record when a link is created. When the predicate returns false, the create call fails with 422 (e.g. "draft records cannot be shared"). Evaluator is the same one used by sharing rules.

Nothing evaluates it. ShareLinkService.getPolicy() builds its policy object from enabled / allowedAudiences / allowedPermissions / maxExpiryDays / redactFields and never reads eligibility; createLink() runs no predicate anywhere. A read across the whole installed platform at 17.0.0-rc.6 finds no consumer of the key at all — the only other hits for the word are unrelated prose in driver-sql.

The sibling keys are all genuinely enforced, which is what makes this one easy to miss in review:

key	measured on 17.0.0-rc.6
enabled	ENFORCED — false ⇒ every create refused, SHARING_NOT_ENABLED
allowedAudiences	ENFORCED — signed_in refused 422 AUDIENCE_NOT_ALLOWED
allowedPermissions	ENFORCED — a non-view grant refused 422
maxExpiryDays	ENFORCED — a longer expiry refused 422 EXPIRY_TOO_LONG
redactFields	APPLIED to every token-served response
eligibility	INERT

Measured end to end

Driving the real ShareLinkService against an object declaring exactly what the docs suggest —

publicSharing: {
 enabled: true,
 allowedAudiences: ['public', 'link_only'],
 allowedPermissions: ['view'],
 redactFields: ['owner_id'],
 eligibility: "record.status == 'published' && record.audience == 'public'",
}

createLink(published + public, audience 'public') → OK
createLink(published + INTERNAL, audience 'public') → OK ← should be 422
createLink(DRAFT + public, audience 'public') → OK ← should be 422
resolveToken( the internal link , {}) → SERVED, anonymously

The last line is the impact: GET /api/v1/share-links/:token/resolve has no auth check, reads the record under SYSTEM_CTX and returns it. So the record an author believed unshareable is served to a caller with no principal.

Severity is bounded by the fact that link creation itself requires authentication (isAuthenticated(ctx) on POST /share-links) plus read access to the record — so this is not an anonymous-to-anonymous hole. It is: any staff user who can read a record can publish it to the open internet, past a policy the object author wrote specifically to prevent that, and the policy raises no error while being ignored. That is the shape a restrictive policy must never fail in — the schema's own history note beside this block makes the point about the sibling keys:

On a policy whose whole job is to be restrictive, a silently dropped key fails OPEN.

Why an app cannot work around it

Worth recording, because the obvious mitigation looks available and is not. The chokepoint exists: createLink persists every link with one engine.insert('sys_share_link', row, { context: SYSTEM_CTX }), and a beforeInsert hook on sys_share_link was measured working against a real ObjectQL engine — it fires despite the system context (triggerHooks filters on object name and session.skipAutomations, which that context does not carry), ctx.api reads the candidate record, and a throw refuses the link. It covers the console share dialog and a raw REST create alike.

But a metadata app cannot register it. validateCrossReferences in @objectstack/spec refuses any hook whose object is not in the stack's own objects:

Hook 'share_link_article_eligibility' references object 'sys_share_link' which is not defined in objects.

collectObjectNames reads config.objects only, so there is no wildcard escape either — '*' is not in that set. So the rule is expressible, enforceable, and unreachable from where apps live.

Two routes

A. Implement it. Evaluate the predicate in createLink before the insert, refusing with 422, using the same evaluator sharing-rule conditions use. Note that compileCelToFilter (the sharing-rule path) compiles to a pushdown filter and rejects things a record-level predicate should accept — has(record.x) among them, per objectstack-ai/hotcrm's measured operator matrix — so "the same evaluator" may need to mean the record-level one rather than the filter compiler. Worth deciding explicitly, since the TSDoc already promises the sharing-rule evaluator.

B. Remove the key, per #3865 / ADR-0078 precedent, so that authors cannot write a policy that silently does nothing. If B, @objectstack/spec's strict object will then reject eligibility outright, which is the loud failure this needs — and the docs paragraph promising the 422 must go with it.

A is worth preferring here, unlike #3865: an eligibility gate is the one thing that makes publicSharing safe to enable on any object holding a mix of public and internal records, which is most of them. Without it the only safe posture is enabled: false, and that is the posture objectstack-ai/hotcrm#1103 shipped — the feature was dropped rather than approximated.

Repro environment

17.0.0-rc.6 as pinned by objectstack-ai/hotcrm, @objectstack/plugin-sharing from that pin, driven through ShareLinkService directly and through a real ObjectQL + InMemoryDriver. Happy to hand over the probe scripts if useful.

---

Generated by Claude Code

[hotlong]

Triage: lands in @objectstack/plugin-sharing (ShareLinkService.createLink) → domain:identity; pm:queue via route A (implement the declared predicate), not escalated: the TSDoc beside the key already declares the full contract — predicate evaluated at link creation, false ⇒ 422, sharing-rule evaluator — so enforcing it is restoring a declared invariant (the named immediate-action class), while route B (remove the key) would be a published-capability removal and is not needed when A restores exactly what is declared. The card's own analysis prefers A for the same reason: without eligibility, the only safe posture on mixed-visibility objects is enabled: false, which is what a real app (hotcrm#1103) shipped.

target:v17 stamped: public contract declared≠enforced on a restrictive security policy that fails open — class ② (declared≠enforced public contract) and class ④ (release-notes-apology material: any staff reader can publish a record to the open internet past a policy written specifically to prevent it, with no error). Same board rationale as #7799/#7807.

Implementation guards for dispatch:

• Evaluator choice is load-bearing: the TSDoc promises "the same evaluator sharing rules use", but the card measured that compileCelToFilter (the pushdown path) rejects record-level constructs like has(record.x) — the promise's intent is record-level evaluation of the candidate record. If the dev finds honoring the record-level semantics requires changing the declared contract text, that is a fork: stop and report, don't silently pick.
• Refusal needs code + status assertions (422, named code) per the rejection-case minimum.
• The sibling-keys table on the card is the regression surface: all five enforced siblings must stay enforced.
• The filer's beforeInsert-on-sys_share_link measurement is context, not the fix — the fix belongs in createLink itself.

Size/model suggestion: M, mode:cloud, model: opus.

---

Generated by Claude Code

[huangyiirene]

Claim: PM loop round 3 (domain:identity seat #6022)
Session: session_01D6Qi9sYxhaRwj7TYiD5MWg
Branch: claude/issue-7861-share-link-eligibility
Worktree: objectstack-issue-7861
Domain: domain:identity
File surface: packages/plugins/plugin-sharing/src/share-link-service.ts (createLink / getPolicy) + its tests. ⚠️ packages/spec/src/data/object.zod.ts is out of surface — route A restores what the key already declares; if honoring record-level semantics turns out to require changing the declared contract text, that is the fork the triage note names: stop and report, ⛔ do not silently pick.
Container & model: M (security-critical, evaluator choice is load-bearing), mode:cloud, model: opus — matches the triage Size/model suggestion line, adopted as-is.
Serial constraints cleared: plugin-sharing is free — this lane's four sharing PRs (#7797, #7806 and predecessors) all merged; nothing in flight touches share-link-service.ts. ⚠️ Three other queue cards target this package (#7807, #7858, #7795) and are held behind this one per same-package serialization.

Premise re-verified on current origin/main before claiming

The card was filed 21:15Z yesterday and main has taken ~25 merges since. Re-checked: eligibility is still declared in object.zod.ts's publicSharing with the TSDoc promising "evaluated against the candidate record when a link is created … the create call fails with 422", and ShareLinkService.getPolicy() still builds its policy from the five sibling keys without reading it. The defect stands.

Why this is dispatchable rather than escalated

Recording the reasoning because the card offers two routes and one of them is not mine to take. Route A (implement) restores an invariant the platform already declares — the named immediate-action class, and it narrows the accept set rather than widening it. Route B (remove the key) would be removal of a published capability and lands in packages/spec, i.e. a different seat and a maintainer call. Triage ruled A; the card's own analysis prefers A; and the decisive evidence is that a real app shipped enabled: false rather than approximate the missing gate.

The four guards from triage go into the dispatch verbatim

1. Evaluator choice is load-bearing — the TSDoc promises "the same evaluator sharing rules use", but compileCelToFilter is the pushdown path and rejects record-level constructs like has(record.x). Intent is record-level evaluation of the candidate record. Divergence between intent and declared text ⇒ fork ⇒ report.
2. Refusal needs code + status (422 + a named code) — toThrow() alone does not constitute a rejection test.
3. The sibling-keys table is the regression surface — all five enforced siblings must stay enforced; a fix that quietly changes enabled/allowedAudiences/allowedPermissions/maxExpiryDays/redactFields behaviour has broken more than it fixed.
4. The filer's beforeInsert measurement is context, not the fix — the fix belongs in createLink.

⚠️ Adding one of my own, from the card's own impact line: the harm is at resolveToken, which serves anonymously under SYSTEM_CTX. The acceptance evidence must therefore be end-to-end — that the ineligible link is never minted — not merely that createLink throws in a unit fake.

---

Generated by Claude Code