Support glob patterns in features.network_proxy.unix_sockets
Summary
[features.network_proxy].unix_sockets currently accepts a map keyed by absolute paths, but those keys are treated literally. There is no way to allow a bounded family of dynamically named Unix sockets without allowing an entire parent directory or setting dangerously_allow_all_unix_sockets = true.
Current behavior
For example, this does not match /private/tmp/service-123.sock:
[features.network_proxy]
enabled = true
unix_sockets = { "/private/tmp/*.sock" = "allow" }
In the macOS Seatbelt implementation, configured paths are normalized as absolute paths and emitted as subpath rules; no glob matching is performed. See normalization and Unix-socket policy generation.
The current directory-level workaround:
unix_sockets = { "/private/tmp" = "allow" }
also permits every Unix socket under /private/tmp, which is wider than necessary.
Request
Support an explicit, documented glob syntax for unix_sockets, for example:
unix_sockets = { "/private/tmp/*.sock" = "allow" }
The implementation should preserve existing literal absolute-path semantics and fail closed for invalid or ambiguous patterns. The generated Seatbelt policy should remain bounded to the intended matching paths.
Motivation
Developer daemons often create Unix sockets with dynamic filenames. A narrowly scoped glob would avoid choosing between an overly broad directory allowlist and dangerously_allow_all_unix_sockets = true.
Scope
This request is specifically about AF_UNIX configuration. It is not intended as a workaround for daemons that use TCP loopback instead of Unix sockets.
1 Comment
Implementation notes for this, from the current code:
(regex #"...")filters whereverliteral/subpathare used today, so a glob entry can compile to an anchored regex rule (^/private/tmp/[^/]*\.sock$) in the generated profile instead of widening to a directorysubpath. No userspace matching needed on that platform.network-proxy/src/state.rs,proxy.rs— Windows drops it entirely). Glob semantics need to land in both, or the same config will mean different things per platform.*in a key is treated as a literal path byte, so adding glob interpretation is technically a behavior change. An explicit form ("glob:/private/tmp/*.sock") or a documented "keys containing*/?are globs" rule keeps existing literal configs unambiguous. Translating*→[^/]*(single component, as you proposed) avoidssubpath-style over-grant.