security(github-copilot): warn and optionally refuse default token password on shared FS

[pjdoland]

Summary

The default NBI_GH_ACCESS_TOKEN_PASSWORD is a public literal. On a shared-home cluster, anyone with read access to another user's ~/.jupyter/nbi/user-data.json can decrypt their Copilot OAuth token using the documented default. admin-guide.md and PRIVACY.md already call this out, but the code did nothing programmatic to prevent it: no startup warning, no refusal-to-write, no FS-mode probe.

Solution

Add two opt-in guardrails on the token write path:

Always-on WARNING when the default password is in use. Fires on the first read or write of the stored token (per process), so an operator sees it in the boot log of any session that touches the file. The message names the env var and the documented escape hatches. When the directory that holds user-data.json is readable or writable by group or other (S_IRGRP/S_IROTH/S_IWGRP/S_IWOTH), the message escalates and names the directory path so a log triage finds the file.

Opt-in refusal. Set NBI_REFUSE_DEFAULT_TOKEN_PASSWORD_ON_SHARED_FS=1 and the write is refused entirely when default password AND group/other-accessible directory both hold. The refusal is opt-in so single-user deployments with incidentally-loose home modes (the default umask 0o022 shape) keep working. Admins who knowingly accept the risk during a rollout, or in single-user contexts where the dir mode is incidental, opt back in per pod with NBI_ALLOW_DEFAULT_TOKEN_PASSWORD=1.

The shared-dir check is POSIX-only; on Windows the gate is a no-op because S_IRGRP/S_IROTH don't map onto NTFS ACL semantics. Env-var parsing reuses the same vocab as _resolve_bool_with_env (true/1/yes/on, case-insensitive) so admins don't have to remember a different set of accepted values for this knob.

The write-bits (S_IWGRP/S_IWOTH) count too: a writable parent dir lets a neighbor plant a forged user-data.json so the next session reads the attacker's token, which is the same shape of damage as a readable parent leaking the existing token. The audit specifies "world-readable" but flagging write is cheap defense in depth.

Testing

tests/test_default_password_refusal.py covers:

• Warn fires on the read path AND the write path. The read-path test now also asserts the token IS still returned (a regression that aborts the read on warn would silently log the user out).
• Warn is one-shot per process (subsequent calls don't add log lines).
• Warn does not fire when the password is overridden.
• Escalated warn includes the directory path so an operator triaging logs can find the file. The non-shared branch omits the directory path so log analysis can distinguish the two postures by message content alone.
• Refusal opt-in matrix: default-off (no refuse), opt-in shared (refuse), opt-in private (no refuse), opt-in + opt-out (no refuse), opt-in + non-default password (no refuse).
• End-to-end: refused write returns False, the file is not created, the error log names the file.
• End-to-end happy path: write succeeds when refusal not engaged.
• POSIX-only tests are skipped on Windows.

Full suites: pytest 773 pass, tsc clean, prettier clean, jest clean.

Risks / follow-ups

• Behavior change: nothing changes by default. Operators must set NBI_REFUSE_DEFAULT_TOKEN_PASSWORD_ON_SHARED_FS=1 to engage the refusal. The always-on WARNING is new noise for any deployment running with the default password, but only one line per process; a deployment that already sets a per-user password sees no new logs.
• Silent refusal UX: when the gate refuses a write, the user sees the GitHub Copilot login succeed (the in-memory session is fine) but "remember login" silently fails. The server log is the only signal. Tracked as a separate follow-up to surface this in the chat UI via a token_persisted: false field on the login-status event; this PR is opt-in (the admin who sets the env understands the tradeoff) so in-app feedback is a UX enhancement rather than a regression blocker.
• Default-deny via shared-FS heuristic: an alternative would be to default-deny on detected NFS mounts / JUPYTERHUB_USER presence, so cluster deployments get the protection without an extra env. Out of scope here; the opt-in flag is the conservative first step.
• Companion file-mode hardening: enforcing 0o600 on the user-data.json file (not just the directory) is tracked as a separate audit item. With that mode, the directory check becomes belt-and-suspenders; without it the dir check is the primary defense.