[socket] Better permission handling

[LaurenceJJones]

What would you like to be added?

From 1.6.1 users will be able to create unix sockets for LAPI as well as AppSec component, however, we didn't want to handle permissions within the configuration file since we dont want another option. On the one hand we could just blanket do 666 and since authentication is done via JWT / API Keys the risk is minimal, however, this does not solve the UID/GID problem and I have been researching how others handle this.

So the major one I investigated was Docker, docker has a service file called docker.socket which creates the file on disk and the parent service docker.service loads after this. The primary function of docker.socket is simply to set the UID and GID and the basic permissions of 0660

Example

01:30:57 root@test ~ → systemctl cat docker.socket
# /lib/systemd/system/docker.socket
[Unit]
Description=Docker Socket for the API

[Socket]
# If /var/run is not implemented as a symlink to /run, you may need to
# specify ListenStream=/var/run/docker.sock instead.
ListenStream=/run/docker.sock
SocketMode=0660
SocketUser=root
SocketGroup=docker

[Install]
WantedBy=sockets.target

And within the code base of Docker when it tries to create the unix socket it inherits the GID of the socket which is primarily the one case I keep running into.

https://github.com/docker/go-connections/blob/5df8d2b30ca886f2d94740ce3c54abd58a5bb2c9/sockets/unix_socket.go#L88

I believe we should maybe implement something like this for handling of permissions create a crowdsec.socket service file that can be enabled by a user then they can simply change the listen_socket and url within the configuration files to create them. Then CrowdSec will simply just inherit the permissions on the socket itself rather than worrying about the implementation in the configuration OR as stated at the top we just do 666 🤷🏻

/kind enhancement

Why is this needed?

To allow users to have better control of socket permissions without the need to bloat code or bloat the configuration files with yet another option.

[LaurenceJJones]

Discussing internally with the team it seems 666 does not impose a risk to end users since we do extra authentication checks on all requests and if the user puts the socket in normal /run/ then a standard user should not be able to delete the socket as they do not have write permissions on the parent folder