caddy icon indicating copy to clipboard operation
caddy copied to clipboard

Allow one to specify file permissions for unix sockets

Open emilylange opened this issue 4 years ago • 3 comments

Caddy supports unix sockets via unix//path/to/unix.socket[^1] [^1]: https://caddyserver.com/docs/conventions#network-addresses (perma link)

Those currently will infer the sockets' file permissions from the shell's set file-creation mode mask (umask)[^2]. [^2]: That is just how the Golang stdlib does it

Usually something along the following:

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

:information_source: 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 :woman_shrugging:

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). Ports aren't a thing with unix sockets, so that should be safe.

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).

emilylange avatar Apr 02 '22 22:04 emilylange

Not a bad idea, will consider this! Thanks :)

mholt avatar Apr 26 '22 15:04 mholt

Not sure if this belongs here or into a new issue, but is there a possibility to support setting the socket ownership—at least the group?

I have a use case where I'm running Caddy behind cloudflared because it's on a private network with dynamic public IP. To increase security, I would like to restrict permissions so that only cloudflared can connect to Caddy by making the sockets owned by a group that only Caddy and cloudflared are members of.

sybereal avatar Jul 06 '22 21:07 sybereal

Ye, that would make sense on a per-socket basis. Feel free to open a new issue :)

For now, you would need to override the Group=caddy^1 with your newly created group name and add UMask=0002^2 in Caddy's systemd service.

See https://caddyserver.com/docs/running#overrides

After #4741 has been merged (and released) you should remove the UMask= again and use unix//path/to/unix.sock|0660 instead :innocent:

emilylange avatar Jul 07 '22 02:07 emilylange