Closed squalus closed 1 year ago
Did they use the same user or a same group?
Did they use the same user or a same group?
Yeah, it's owned by the user and group of the process.
For the fiew times I've used the unix sockets, I've never had this issue by setting the same user or at least the same group for both the server and the client.
I feel that using a chmod
to fix the issue is not the right way.
@cyberb Did you ever encounter this issue since you have implemented the unix socket support?
It seems like a program listening on a socket is generally responsible for the permissions and ownership of its socket. The use case here is that I have standardfile running as its own user, and a reverse proxy running as its own user. Standardfile listens on a socket owned by standardfile:standardfile rw-r--r--
So the reverse proxy can't access the socket since it's running as a different user.
Some examples in the wild:
PostgreSQL: https://www.postgresql.org/docs/current/runtime-config-connection.html (unix_socket_permissions, unix_socket_group)
PHP-FPM: https://github.com/php/php-src/blob/5174ee23537d82d5ea20ef84ce40cf274c74c5ed/sapi/fpm/www.conf.in#L42 (listen.mode, listen.owner, listen.group)
Redis: https://github.com/redis/redis/blob/8203461120bf244e5c0576222c6aa5d986587bca/redis.conf#L156 (unixsocketperm)
PostgreSQL is the cleanest one to me here: allow the user to configure a mode and a group. Maybe standardfile should have a socket_group
configuration too?
It doesn't have to be done with a chmod. It can also be done by setting the umask instead and restoring it after listening.
Seems reasonable to me. I also thought about umask, but I am not sure what is the best practice here, so I would accept this for now.
Ok the option seems legit.
I ran into a problem using UNIX sockets: the socket was created with permissions that didn't allow the reverse proxy to read it.
Add
socket_mode
configuration option to set the permissions on the UNIX socket.example config: