Caddy supports unix sockets via unix//path/to/unix.socket¹

Those currently will infer the sockets' file permissions from the shell's set file-creation mode mask (umask)².

Usually something along the following:

❯ umask # octal
022
❯ umask -S # symbolic
u=rwx,g=rx,o=rx

ℹ️ A user only needs rw (read/write) access to a socket to be able to use it. x (execute) is not required.

However, one might want to modify the permission of a socket via json config or within the Caddyfile.
Not only is this optionally more declarative, but would properly allow for granular access control.

For example:

1. Admin API shall only be accessible for user caddy
2. vhost_1 shall be accessible for all users on the host
3. vhost_2 shall only be accessible for users of a specific group

Though the last one (vhost_2) won't work with the default systemd service, because it runs as caddy:caddy, thus inferring caddy:caddy as owner.
The idea is to only run a chmod. An additional chown would make sense for vhost_2 though 🤷‍♀️

Example use-case and context where the default u=rwx,g=rx are insufficient, because both caddy and debian-tor users need to access the socket: https://caddy.community/t/new-user-cant-get-darkweb-site-host-working/15491

@francislavoie and I discussed that in slack a bit, where he proposed unix//path/to/unix.sock|0666 as an extended version of unix//path/to/unix.sock but with os.Chmod(socketPath, 0666).

Currently, in 2.5.0-beta.1, a socket with |0666 appended will just get directly passed through and create the socket at /path/to/unix.sock|0666 (literally).