From d223a93039c47c0772486da29cf95608adc7b804 Mon Sep 17 00:00:00 2001 From: Dai Ha Date: Thu, 3 Sep 2026 16:38:56 +0700 Subject: [PATCH] fleetd #184: correct sshAuthSock guidance --- fleetd/fleetd.example.yaml | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/fleetd/fleetd.example.yaml b/fleetd/fleetd.example.yaml index 9829550..6c0efc9 100644 --- a/fleetd/fleetd.example.yaml +++ b/fleetd/fleetd.example.yaml @@ -676,13 +676,15 @@ guard: # every name here NOT also in `allow` is overlaid with a non-secret sentinel value before # the pane's login shell runs — real protection only for names that shell does not itself # re-export (see the ROUND-2 CORRECTION note above). Under allow-list: reporting only. -# sshAuthSock → whether SSH_AUTH_SOCK may pass through under allow-list ("allow") or must be -# blanked like any other non-derived name ("block", the default). This is a decision you -# have to make explicitly: SSH_AUTH_SOCK is a handle to YOUR ssh-agent, and a member -# holding it can sign with your keys — it sits in no secret file and looks like no -# credential, which is why it slipped past three earlier tickets (gitea #110). Blocking -# it breaks git over SSH inside members (push/fetch authenticate as you); use HTTPS -# remotes or scoped deploy keys instead of allowing it lightly. +# sshAuthSock → whether SSH_AUTH_SOCK may pass through under allow-list ("allow") or is omitted +# from the member environment ("block", the default). Blocking it only omits the +# inherited ssh-agent path. It discourages automatic use of the operator's agent. +# It does not deny same-user access to that socket. It also does not block SSH keys that +# are readable on disk. Git over SSH may still work from inside a member. Keep the block: +# it is correct and costs nothing, but it is not a control. A member runs as the same OS +# user as the lead. Inside one uid, ordinary Unix permissions provide no meaningful +# confidentiality boundary. A real boundary needs a different OS user or OS-level +# confinement, such as a container or VM. That is the open question in fleetd #184. # # HOT-RELOADABLE the same way `fleet:` is (CB-559): read fresh on every spawn, so editing this list # and reloading config (or restarting) changes what the NEXT spawn inherits; already-running members