Viewing a higher-tier user profile writes a false 'security.privilege_violation' audit + security-log entry

Area: Admin deep-dive (trust/safety) (audit p15a) · Surface: GET /admin/users/{id} (AdminUserController@show via Concerns/ModifiesUsers::assertCanModify) · Dimension: security · Severity: minor

Whenever a role-4 admin merely opens the profile page of a super-admin (role 5), the system records a 'security.privilege_violation' entry in the tamper-evident append-only audit log and emits a security WARNING, plus flashes a permission-denied error to a read that actually succeeded. This poisons the audit trail / SIEM signal with false positives on a benign read and degrades the value of genuine privilege-violation alerts. OWASP A09 Security Logging integrity (false events).

Evidence

AdminUserController.php:124 calls `$canModify = $this->assertCanModify($targetUser, 'view');` purely to decide whether to render action buttons. assertCanModify (Concerns/ModifiesUsers.php:37-55) is not a pure predicate — on the deny path it writes an append-only audit row and a security-log WARNING:
  AuditLog::record($actor['id'], 'security.privilege_violation', "Attempted to view user #{...} (role {...})", ...)
  $this->logger->security('WARNING', 'Privilege ceiling violation', [...])
  $this->flash('error', 'You do not have permission to perform this action on that user.')

Suggested fix. Add a side-effect-free permission check (e.g. a `canModify(array $target): bool` that just compares roles) for read/render gating, and reserve assertCanModify (which logs + flashes) for actual mutation attempts.

Filed by the automated tenant-app audit and adversarially evidence-verified. Status: verified. Open — not yet actioned.