Let a group share the info API too, and serve it on windows

The info API is for other programs on the host, and on unix the only
setting between "the user nebula runs as" and "everyone" was a manual
chgrp that the next bind undid; on windows it was not served at all,
because which accounts a pipe admits had not been decided. The control
socket's `group` decides it, and the info API takes the same key.

- `local_api.info.group`: the socket is handed to the group at 0660
  unless `socket_mode` says otherwise, and a mode that gives a named
  group nothing is refused with the mode that would
- windows: served on a named pipe, the group an ACE on it as on the
  control pipe; the e2e test's helpers dial unix sockets, so it still
  skips there
- a changed group or mode on a reload is applied to the socket in place

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This commit is contained in:
Matt RichardsonandClaude Fable 5.1 committed 2026-10-21 12:26:57 -04:00
1 parent 613c7e3061
commit 3fb29d6444
7 files changed
+153 -30

No files matched your search

+4 -5
View File
@@ -33,11 +33,10 @@ const network = "pipe"
// exists so a Server is built the same way on every platform.
var currentUID = func() uint32 { return 0 }
// infoSupported is false here. A pipe has no mode to open to other accounts, and the
// security descriptor listen builds admits the daemon's account alone, which is the
// opposite of what the info API is for. Serving it on windows means designing which
// accounts a pipe admits, and that has not been done.
const infoSupported = false
// infoSupported is true here: the pipe's security descriptor is what a mode is on unix,
// and the group an operator names in the config is the way to open it to other
// accounts, as it is for the control pipe. The mode itself means nothing to a pipe.
const infoSupported = true
// listen creates the named pipe at path with a security descriptor that admits the user
// nebula runs as, SYSTEM and Administrators, and the group acc names, if any, for