Policy cannot grant access to bugs the requesting user reported (no identity-relative matcher)

[plusky]

Problem

There is no way to write a rule that grants access to bugs the requesting user
themselves reported. A policy that follows the recommended safe default —

[[rule]]
name = "group-restricted"
action = "deny"
[rule.match]
group_restricted = true

— also hides every group-restricted bug the API key's own account authored, and
nothing in the matcher vocabulary can carve them back out.

This is a slightly odd outcome, because Bugzilla already grants that account access
to those bugs: it returns them with is_creator_accessible: true. The guard is
strictly more restrictive than the credential it is using, with no way to express
"...except the ones I filed".

Why it can't be expressed today

Matcher accepts ten fields, none of which relate to identity:

products, components, groups, group_restricted, statuses, severities,
priorities, summary_contains, whiteboard_contains, younger_than_days

All ten describe the bug's content or classification. None describes the
relationship between the bug and the caller, so authorship cannot be a criterion at
any position in the rule list.

Why the available workaround is bad

The only lever is to replace the blanket group_restricted = true with an explicit
groups = [...] glob list, so that groups not on the list fall through. That does
make your own bugs readable — along with every other group-restricted bug whose
group nobody happened to enumerate. To recover a handful of bugs you authored, you
open up an entire unenumerated internal corpus. The blast radius is wildly
disproportionate to the intent, and it degrades exactly the guarantee the blanket
rule exists to provide.

Proposal

Add an identity-relative match criterion, resolved against the account that owns the
API key being used for the request:

[[rule]]
name = "my-own-reports"
description = "I can always read what I filed"
action = "restrict"
capabilities = ["read", "comments", "history", "attachments"]
[rule.match]
created_by_me = true

A self-referential form (created_by_me = true, or creators = ["me"]) is
preferable to hardcoding an email address, for two reasons:

• it keeps personal identity out of a file that is typically root-owned, shipped, and
  shared between operators;
• under --transport http the API key arrives per request, so "me" is not a
  property of the server at all and cannot be baked into the policy at startup. It
  has to resolve per request to be correct.

assigned_to_me and cc_me would be the natural rest of the family if you want the
whole set, but the creator case is the one that actually bites.

Security notes

• This cannot widen exposure beyond the credential: Bugzilla still enforces its own
  access control, so a rule keyed on authorship can only ever surface bugs the
  account could already fetch. It narrows the gap between the guard and the
  credential rather than escaping it.
• It should be an explicit opt-in, not implied — an operator running a shared server
  as a service account may specifically not want that account's own reports
  exposed to whoever is talking to it.
• To be useful, such a rule has to sit above the group-consulting deny rules,
  which under current first-match-wins semantics means it also becomes the sole
  arbiter of every other capability for the bugs it matches. That composes badly for
  the same reason described in A restrict rule granting only create silently revokes read access to all matched products #26; operation-aware matching would let both rules
  coexist cleanly.

Notes

bugwarden 0.2.0, --transport stdio, against a Bugzilla 5.x instance.

[plusky]

Correction to the field list above: Matcher accepts eleven fields, not ten — I omitted keywords, which is used by the shipped embargo-keyword and fresh-security-keyword example rules. Full set:

products, components, groups, group_restricted, statuses, severities, priorities, summary_contains, whiteboard_contains, keywords, younger_than_days

This does not change the request: keywords is still a property of the bug, so all eleven describe content or classification and none expresses the caller's relationship to the bug.