macOS agent.sock chmod 0660 (root:admin) blocks Standard non-admin user helpers

[ToddHebebrand]

Reported by semotech in #bugs (Discord, message 1534284370544824472).

Report (PII-redacted):

Reinstalled via install.sh on 2019 iMac (macOS 14.7.2 amd64, agent 0.103.0): upgrade OK, already enrolled (no --force). Reinstall restored loginwindow helper → Screen Recording prompts returned after reboot. After console login Breeze shows FDA/SR/Accessibility Granted; Remote Desktop still Missing; Desktop unavailable. Also saw Splashtop Streamer Screen Recording prompt on this host — is Splashtop part of Breeze RD on macOS, and must it be granted separately? Disabling loginwindow plist again as workaround.

Bug Summary: macOS “Remote Desktop” permission stuck Missing — Desktop unavailable

Hardware: 2019 iMac (Retina 5K 27", 3.6 GHz 8-core i9, 32 GB, Radeon Pro 580X 8 GB)
OS: macOS 14.7.2 (darwin 23.6.0) amd64
Agent/watchdog: 0.103.0

Symptoms:

• Breeze macOS Permissions: FDA Granted, Screen Recording Granted, Accessibility Granted
• Remote Desktop: Missing (grayed) — banner: required for unattended login-window access on macOS 14+
• Breeze Desktop control unavailable/grayed while user is logged in at console
• No Screen Recording TCC popups after disabling loginwindow helper

Related findings during debug:

• com.breeze.desktop-helper-loginwindow (root, context=login_window) spam-requested Screen Recording / CGDisplayStream failures; moving that plist aside stopped popup loop
• agent.sock was srw-rw---- root:admin — user-session helper got permission denied until chmod 666 (breaks Standard users)
• Reinstall/upgrade via install.sh restored loginwindow plist and prompts; did not clear Remote Desktop Missing
• Privacy “Remote Desktop” pane unclear vs Sharing→Remote Management (ARD On on this host)

Questions:

1. How is “Remote Desktop” permission detected/granted on 14.7? Exact System Settings path + binary?
2. With SR+Accessibility+FDA Granted and user_session helper running, why is interactive Desktop still unavailable?
3. Intended agent.sock permissions for user helper?
4. Is disabling loginwindow helper supported, or is that required for Remote Desktop / pre-login?

Filed automatically by @breeze-discord triage. Verify and add labels/repro as needed.

Triage analysis

The core, verifiable defect in this thread is agent.sock permissions on macOS. agent/internal/sessionbroker/broker_unix.go creates the Unix socket and explicitly chmod's it to 0660 (srw-rw----), with a comment stating the intent is 'Allow normal user helpers to traverse the directory and connect to the socket' — i.e. any user-session helper should be able to dial in, with peer-credential/binary checks as the real gate. But 0660 only grants access to the socket's owning group, and on the reporter's machine that group resolved to root:admin, which excludes Standard (non-admin) console users entirely. The reporter reproduced this exactly: dial unix '.../Breeze/agent.sock': permission denied for a Standard user, confirmed the mode/owner (srw-rw---- root:admin), and confirmed chmod 666 unblocks it. This contradicts the code's own stated intent — it should be reachable by any local user's helper, not just admin-group members. The rest of the thread (Remote Desktop permission stuck 'Missing', ScreenCaptureKit timeouts, loginwindow helper TCC prompt spam) traces to a separate mechanism: heartbeat/desktop_access_darwin.go derives RemoteDesktopPermission from a real ScreenCaptureKit capture probe (userhelper/tcc_darwin.go -> desktop.ProbeCaptureAccess), which is distinct from the CGPreflightScreenCaptureAccess-based ScreenRecording flag shown in the UI — so it's expected that the two can disagree, and login-window desktop is intentionally unsupported (Apple blocks synthetic input there, code falls back to VNC). I did not find enough to confirm a separate bug in that path (why the real capture probe stays inconclusive in a granted user session) — that needs more targeted repro/logs.

Affected code

• agent/internal/sessionbroker/broker_unix.go:12-37 — setupSocket() chmods the IPC socket to 0660; comment states intent is for 'normal user helpers' generally to connect, but 0660 restricts access to the socket's group (root:admin on the reporter's box), locking out non-admin Standard users — matches the reporter's exact permission-denied repro and their chmod 666 workaround.
• agent/internal/heartbeat/desktop_access_darwin.go:1-93 — Shows RemoteDesktopPermission/reason derivation (helper_not_connected/missing_permission/virtual_display_unavailable/unsupported_os) used for the separate 'Remote Desktop Missing' question — login-window desktop control is intentionally unsupported by design.
• agent/internal/userhelper/tcc_darwin.go:132-155,345-360 — RemoteDesktop status comes from a real ScreenCaptureKit capture probe (probeRemoteDesktopPermission), separate from the CGPreflightScreenCaptureAccess-based ScreenRecording flag — explains why Screen Recording can show Granted while Remote Desktop stays unresolved.

Potential fix

Change the socket permission model in broker_unix.go: either chmod the socket 0666 (relying solely on peer-credential/binary-path verification, as the comment already assumes is the real gate) or create/chgrp it to a group that all local user-session helpers are guaranteed to belong to, instead of whatever GID the daemon process happens to run under.

Triage analysis, affected code, and fix sketch above were produced by automated investigation (@breeze-discord). Verify before relying on them.

[ToddHebebrand]

Duplicate of #3137 — same defect: the breeze group was created but never applied to agent.sock, which comes up root:admin because macOS gives a new file its parent directory's group.

Fix is in PR #3422 (open, targeted at v0.105.0, not yet merged). Full explanation, the two workarounds to remove, and the verification steps are in this comment on #3137.

Keeping all three open rather than closing as duplicates — referenced with Refs so they survive the merge, and the reporters are the ones who can verify the Standard-user path on real hardware.