caddy
caddy copied to clipboard
caddyserver
Allow setting the owning group for Unix listeners
As I've described in the comments of #4675, it can in some scenarios be useful to set the ownership, primarily the owning group, of a Unix listener created by Caddy, to narrow down the processes/users that are allowed to connect to them.
At the current time, listeners created by Caddy are owned by the Caddy process' primary UID/GID. Granting the caddy group to other services might be undesirable, however, since, even though all of Caddy's state, certs, etc. have no group permissions, it could be used to protect configuration files containing sensitive data: /etc/caddy/Caddyfile might contain basic auth password hashes, so the "usual" way of securing it would be changing the ownership to root:caddy and the file mode to 0640.
While this issue can be worked around by changing Caddy's primary group (e.g. Group= in case of systemd) to the group that should own the sockets and then adding the caddy group as a supplementary group (e.g. using SupplementaryGroups=), there is still the problem that all sockets are owned by the same group. This can be problematic, especially for the admin socket, as there might be Caddy sites one wants to expose to specific applications without permitting access to others.
Any ideas/suggestions how the syntax for that should look like?
Perhaps, making it an extended version of
unix//path/to/unix.sock:0222 like
unix//path/to/unix.sock:mode=0222;group=somegroup
while also allowing
unix//path/to/unix.sock:group=somegroup (defaulting to mode=0200)
and
unix//path/to/unix.sock:mode=0222 (defaulting to group=$groupOfExecutingUser)
?
I kinda like the bare minimum syntax (unix//path/to/unix.sock:0222) from #4741, which is hasn't been merged yet and is currently tagged as v2.6.0 milestone.
Also, I'll most likely end up implement the symbolic file mode representation eventually, which should also somehow fit into all that :thinking:
unix//path/to/unix.sock:u=w,g=w,o=w (0222)
unix//path/to/unix.sock:ugo=w (0222)
unix//path/to/unix.sock:a=w (0222)
unix//path/to/unix.sock:u=w,go= (0200)
unix//path/to/unix.sock:ug=w,o=;group=somegroup (0220)
unix//path/to/unix.sock:mode=ug=w,o=;group=somegroup (0220)
Or should it just default to ug=w (0220) with no way of manually overriding it when specifying a group?
Because u=w,go=/0200 and a=w/ugo=w/0222 wouldn't make much sense when specifying a group, would it?
It seems my email reply was lost in the static. My bad.
In any case, I didn't initially provide any suggestions because I wasn't really happy with the ideas that I did have. However, you make a great point that modes other than 0220 don't really make sense if you're explicitly changing the group. There is no point in restricting owner permissions because they can always add them back, and setting a different group doesn't make any difference if access is granted to the "other" category. I've spent a good while pondering possible scenarios in which there might be a reason to, but I always stumbled across something that would make it unnecessary sooner or later.
Thanks for the update @sybereal . So ... should we close this? (If I understand you right)
Sorry, it seems I wasn't clear. It's not that I think that setting the group wouldn't be useful; if anything, it's the opposite. My point in the previous comment was that I don't see any use case for setting the group and the file mode simultaneously. Setting just the group still has a use case imo.
I didn't want to overcomplicate the syntax, and none of the options that came to my mind accomplished that. However, you make a great point that 0220 is the only sensible mode if a group is specified, since socket access is controlled by a single permission bit. As you've said, assigning a specific group only really makes sense in the case of group access being enabled and other access being disabled. ------- Original Message ------- On Tuesday, July 12th, 2022 at 1:51 PM, IndeedNotJames - notifications at github.com @.***> wrote:
Forwarded by SimpleLogin to @.*** with Re: [caddyserver/caddy] Allow setting the owning group for Unix listeners (Issue #4869) as subject
Any ideas/suggestions how the syntax for that should look like?
Perhaps, making it an extended version of unix//path/to/unix.sock:0222 like unix//path/to/unix.sock:mode=0222;group=somegroup while also allowing unix//path/to/unix.sock:group=somegroup (defaulting to mode=0200) and unix//path/to/unix.sock:mode=0222 (defaulting to group=$groupOfExecutingUser) ?
I kinda like the bare minimum syntax (unix//path/to/unix.sock:0222) from #4741, which is hasn't been merged yet and is currently tagged as v2.6.0 milestone.
Also, I'll most likely end up implement the symbolic file mode representation eventually, which should also somehow fit into all that 🤔
unix//path/to/unix.sock:u=w,g=w,o=w (0222) unix//path/to/unix.sock:ugo=w (0222) unix//path/to/unix.sock:a=w (0222) unix//path/to/unix.sock:u=w,go= (0200)
unix//path/to/unix.sock:ug=w,o=;group=somegroup (0220) unix//path/to/unix.sock:mode=ug=w,o=;group=somegroup (0220)
Or should it just default to ug=w (0220) with no way of manually overriding it when specifying a group? Because u=w,go=/0200 and a=w/ugo=w/0222 wouldn't make much sense when specifying a group, would it?
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>
By default a regular user cannot change owner or group of a file. In most cases where caddy is not run as root, it won't be able to change the group of unix sockets. Instead, using tmpfiles.d can be used for custom ownership/permissions. Wrote a blog post on how I do with caddy. Link
If we end up doing this, the syntax would probably be unix/path|bits|user:group. That would follow on https://github.com/caddyserver/caddy/pull/4741 which added the permission bits syntax.
I'm not sure there's still a need for this though. I don't know how common of a need it is. Leaning towards closing it.
I am no longer actively working on the use case I originally wanted to use this for, so I would not be opposed to closing it.
On the off-chance it ever comes up again, I will see if I can provide a patch myself.