* fix(security): don't grant tool access in the pre-setup window
owner_is_admin_or_single_user() returned True whenever auth was not
configured, which conflated two very different states:
- intentional single-user mode (operator set AUTH_ENABLED=false), and
- the pre-setup window (auth enabled, but no admin created yet).
In the second state, blocked_tools_for_owner() returned an empty set, so
server-execution tools (bash/python) and other admin-only tools were
ungated. The auth middleware already 401s /api/ requests pre-setup, but a
caller that bypasses it (trusted loopback / internal-tool path) could reach
those tools before setup completed.
Treat "not configured" as admin only when auth is intentionally disabled
(AUTH_ENABLED=false), mirroring the AUTH_ENABLED parsing in app.py and
core.middleware. Single-user mode is preserved; the pre-setup window is now
non-admin as defense-in-depth.
Adds regression tests for both states.
Fixes#3201
Supported by Claude Opus 4.8
* refactor(security): reuse _auth_disabled() instead of a duplicate helper
Addresses review on #3506: src/auth_helpers.py already has _auth_disabled()
with the identical AUTH_ENABLED parse. Drop the duplicate
_auth_intentionally_disabled() and call the existing helper via a lazy import
inside owner_is_admin_or_single_user (mirroring the lazy core.auth import) to
avoid any import cycle. Removes the now-unused `import os`. Behaviour and the
two regression tests are unchanged.
Supported by Claude Opus 4.8
---------
Co-authored-by: SurprisedDuck <288741682+SurprisedDuck@users.noreply.github.com>
SurprisedDuck
e115b0155c