FdoSecrets: remember client authorizations across restarts - #13610

A Collection retires (removed from D-Bus, backend reset, deleteLater
scheduled) synchronously when its database closes. Prompts, however,
reference collections via QPointer from timer callbacks outside D-Bus
dispatch, and a QPointer still sees the retired object until its
deferred deletion is delivered. This left two holes, both reachable
when a collection goes away while a prompt targeting it is in flight
(e.g. a concurrent Collection.Delete from another client):

- LockCollectionsPrompt/UnlockPrompt could call doLock()/doUnlock() on
  a retired collection, hitting Q_ASSERT(m_backend) in debug builds.
- UnlockPrompt would hang forever: the retired collection never emits
  doneUnlockCollection (its service connections are severed on
  retirement), and the count-based completion condition could no
  longer be satisfied, so the Completed signal never fired and the
  client waited indefinitely. The same accounting also hung when an
  entry was already destroyed by the time promptSync ran.

Following the same principle as DeleteCollectionPrompt: restore the
invariant that a non-null collection reference is usable, instead of
relaxing the asserts.

- LockCollectionsPrompt clears retired collection references on
  collectionAboutToDelete; a retired collection is skipped exactly
  like a destroyed one.
- UnlockPrompt tracks awaited collections in an explicit pending set,
  pre-registered before issuing any doUnlock so that synchronous
  completions (already-unlocked databases) cannot prematurely trigger
  the item unlock step. Retirement is accounted as a rejection and
  re-evaluates completion, so the prompt always terminates.
- Add regression test testServiceUnlockConcurrentDelete covering the
  unlock/delete race; verified to fail (hang detected via signal spy
  timeout) without this fix.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Service::m_unlockingDb tracks databases with an unlock dialog shown to
prevent duplicate dialogs. If the DatabaseWidget is destroyed while
its dialog is open (e.g. the database is deleted via a concurrent
D-Bus call), dialogFinished never fires for it and the entry stayed
forever, keyed by a dangling pointer. The pointer was only ever
compared, not dereferenced, but the stale entry permanently blocked
doUnlockAnyDatabaseInDialog (used by unlock-before-search), and a
future widget allocated at the same address would have been refused an
unlock dialog as well.

Track a cleanup connection on the widget's destroyed signal alongside
the existing databaseUnlocked oneshot, covering both the per-database
and the unlock-any-database flows. Extend the
testServiceUnlockConcurrentDelete regression test to reopen the
database after the concurrent delete and verify the unlock dialog
still appears; without the fix the test times out in SearchItems
waiting for a dialog that never shows.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

The item access confirmation dialog used to hold raw Entry pointers in
its model, its deny buttons, and its result signal. When the database
locks or closes while the dialog is open, DatabaseWidget replaces the
Database and destroys every Entry, while the dialog stays up: painting
the model, or answering the dialog, then dereferenced freed entries
(crash in UnlockPrompt::itemUnlockFinished via Entry::uuid, see the
backtrace in keepassxreboot#9104).

Make the dialog self-contained: snapshot each entry's uuid and display
data (title, username, icon) at construction and report decisions as a
QHash<QUuid, AuthDecision>, so the dialog never touches an Entry again
after it is shown.

On the UnlockPrompt side, restore the invariant that a non-null item
reference implies a usable backend: track items with QPointer and clear
all references as soon as an item retires (Item::itemAboutToDelete),
mirroring how collection retirement is handled. A decision for an item
that has retired counts as rejected, so the prompt completes as
dismissed instead of reporting success for nothing.

Finally, match the browser behavior: the dialog now withdraws itself
(rejects) when a collection it is asking about locks or goes away,
instead of keeping a stale question on screen.

Fixes keepassxreboot#9104

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AqHu6RpvLpaoH2aUGSYQzR

Client identity records (match rules + catch-all decision) are stored in
the database metadata customData, one key per record under the new
FDO_SECRETS_CLIENT_ prefix, keyed by a stable DBusClientId. A rule is a
conjunction of conditions on the client's process hierarchy - executable
path, name or content hash at a given ancestor depth - and a record
matches when any of its rules does. Per-entry decisions live in each
entry's own customData, keyed by DBusClientId, so they follow the entry
through moves, deletion and merges; the record's allEntries decision is
the catch-all for entries without one.

One key per record (rather than one blob for all clients) matters for
merging: metadata customData merges whole-map on a single timestamp, so a
monolithic value would lose updates on every cross-machine sync. The
prefix is registered in CustomData::isProtected() so records survive
merges against databases that never saw them. Record parsing fails
closed: a malformed or unknown condition invalidates the whole record
instead of silently broadening what it matches.

Part of keepassxreboot#6458.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016NdKDY7EiJFUFj1bb8x6XP

DBusClient::exeHash(depth, algo) produces a digest of the executable
content of any process in the client's hierarchy. Reading through
/proc/PID/exe reaches the original binary even when its path has been
replaced or deleted, which makes the digest a reliable complement to the
path. The algorithm is taken by name so stored rules can carry theirs;
only sha256 exists today, and an unknown name is logged and yields an
empty digest.

Failures (process gone, different uid, PR_SET_DUMPABLE cleared, no /proc)
also yield an empty digest so hash-based match conditions fail closed.
Results including failures are cached per connection: a live process
cannot change its /proc/PID/exe, a reused pid must not produce a
different hash, and the unsupported-algorithm log fires once instead of
per lookup.

The method is virtual so tests can substitute hashing for their synthetic
process hierarchies.

Part of keepassxreboot#6458.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016NdKDY7EiJFUFj1bb8x6XP

Matching happens in two phases so decisions never iterate records: first
the live client resolves to at most one identity record in a database
(any rule whose conditions all hold selects its record; among overlapping
records a denying catch-all wins, then the earliest created), then the
<entry, client> decision is a plain lookup of the entry's own decision
with the record's catch-all as fallback. Hash conditions are evaluated
last so hashing only happens once everything cheap already matched, and
anything unavailable or not understood fails the condition rather than
skipping it.

A record whose non-hash conditions identify the client while a hash
condition fails is reported as a fingerprint change instead of a match,
with every failing hierarchy depth collected: the previously authorized
executable content has changed and the user must re-decide.
upsertClientRecord() then re-anchors the stale hashes in place instead of
creating a duplicate record; for an unknown client it creates a record
with the default rule, anchoring each requested hierarchy depth by
executable path and content hash - either alone suffices, since a deleted
binary loses its path but stays hashable through /proc/PID/exe.

The default rule anchors the calling process; when that is a script
interpreter (any script it runs could use a stored authorization) the
anchor extends past consecutive interpreter levels to the first
non-interpreter ancestor.

Records are parsed on each decision instead of being cached: the
customData modification time only has second resolution, so a timestamp
validated cache can serve stale authorizations for changes landing within
the same second. Record counts are small and parsing is microseconds.

Part of keepassxreboot#6458.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016NdKDY7EiJFUFj1bb8x6XP

Decisions persisted in the database are consulted wherever the runtime
ones already were: whether an item reports itself as locked, the checks
guarding reading and writing a secret, and the unlock prompt, which no
longer asks about entries the database already answers for.

Service::authDecision() is the only place a stored decision and the state
of the current connection are combined, so no caller can arrive at a
different answer: denials win within a layer, and a decision limited to
the current request wins over a stored one. DBusClient is reduced to that
connection state; a stored catch-all is never copied into it, which is
what keeps it from leaking into another database.

The access dialog answers a request with Allow or Deny for the checked
entries, with per-entry "Deny for this program" for the exceptions, and a
separate Scope: Once, Selected, or Selected + future. Verdict and reach
are independent, so no combination is meaningless — a client-wide decision
is by nature one that is stored, which is why it is a scope rather than a
pair of buttons whose persistence depended on a check box. The
connection-lifetime tier disappears with it; users could not perceive it.

The process tree gains a Match column selecting what a stored decision
anchors on. Only the calling process is proposed: which ancestor
identifies anything is a judgement about the user's setup, and picking one
would suggest a safety this cannot deliver, since the usual ancestors are
shells, terminals and session managers that everything descends from.

Warnings cover an unreadable executable, a general purpose tool as the
caller (interpreters, shells, and clients like secret-tool, which ask on
behalf of whatever invoked them), and executable content that changed
since the decision was stored. Each of them starts the scope at Once, and
the tool warning says outright that storing a decision is discouraged
rather than offering a remedy that would not hold.

Per-entry denials are recorded as intent and mapped when the dialog
concludes, so the order of clicks never changes the outcome, and a denial
stored next to a future-covering allow keeps that entry denied.

The Secret Service page of the database settings lists the client identity
records persisted in the database, with a summary of what each one matches
and what it decided, and lets the user inspect, edit and remove them. A
record editor dialog covers the matching rules (per hierarchy depth: path,
name or executable digest, with a digest computable from a file on disk)
and the catch-all decision; per-entry decisions are listed there but can
only be removed, since they are granted through the access prompt and
changed on the entry itself.

Edits are staged and written when the settings are saved, like every page
of this dialog except the browser one. Nothing is written before that, so
removing a record needs no extra confirmation.

Overlapping records are a configuration smell rather than an error: the
resolver still picks deterministically, so both the list and the editor
only warn about it. recordsOverlap() answers this statically by looking
for a contradiction-free pair of rules, which is why conditions at
depths one record does not constrain never rule out an overlap.

The page has to fit the settings dialog, which gives its pages no
horizontal scrollbar: the warning wraps (an unwrapped message widget makes
its full text the minimum width of the whole page), the rules column gets
whatever the other two do not need, and the exposed group tree is as tall
as its contents instead of taking half the page.

Decisions live in the entry's own customData, so the entry editor gains a
Secret Service page listing them: which client, allow or deny, with a
decision left behind by a since-removed record marked as unknown rather
than shown as a bare uuid. Every row keeps its allow/deny combo open, one
that has to be discovered by double clicking might as well be read-only,
and a decision can be added for any client the database knows about but
that has no decision on this entry yet, searchable by name or by what its
rules match.

The page edits the editor's staging copy of the customData, so its changes
follow the usual Ok/Apply/Cancel and history semantics of the entry editor,
including a revert restoring the decisions of the restored version, the
same as the browser integration settings kept alongside them. The page is
hidden while Secret Service integration is off.

The Authorization tab lists connected applications, so it is the place to
answer "is this the client I already trust?". Each row now names the
identity record it resolves to in every open, exposed database, or reports
that its executable changed and it will have to be authorized again.

The resolution is cached per client and dropped whenever a database is
opened, closed, locked, unlocked or modified: resolving hashes the client's
executable, which is far too expensive to redo on every repaint.

The Manage column goes away with it. Its Reset button cleared decisions
that no longer outlive a single request, and its Disconnect button only
dropped a connection the client reopens on its next call; neither belongs
next to authorizations that live in the database and are managed there.
Since the test override now stands in for a connected client, it is
registered as one so it appears in this list like any other.

All three pages are now called "Secret Service": the settings dialogs
elided the longer name anyway.

The user documentation gains what the access request now asks and what it
means to remember a decision, how a client is recognized and where stored
decisions are managed, and what recognition does not prove: code running
inside a legitimate client inherits its authorizations, scripts sharing an
interpreter are indistinguishable unless the rule reaches further up the
process tree, and a process that hides its executable can never be
recognized.

The screenshots are regenerated, since the access request lost the
"& Future" buttons and both settings pages grew a section, and the tip
about secret-tool prompting on every run is gone: being recognized across
processes is exactly what this feature added.

The implementation README describes the two storage layers, why records
are one custom data key each, the two lookups a decision takes, why
resolution is not cached, and how connection state and stored decisions
combine.