You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On multi-user dev machines (such as is our case), it seems there's no way to prevent one user from sending commands to another user's instance, as it's using a standard TCP port on the machine.
Also, it means the users must agree on which port each of them uses, which might be tedious.
It seems that a solution to both issues would be to allow using unix sockets, which are basically sockets but path-based, supporting file permissions. It seems that using a local file in the user's home directory would naturally propagate that directory's permissions, and avoid conflicts.
The text was updated successfully, but these errors were encountered:
The reason I've originally written it with TCP sockets is that UNIX sockets don't work on windows and I wanted to make it portable.
If someone wants unix sockets and submits a PR that will allow a unix socket in the listen and connect config options without breaking windows and users who are using tcp sockets and/or are using default config I'd be happy to accept that. We could even make unix sockets the default config on *nix systems.
On multi-user dev machines (such as is our case), it seems there's no way to prevent one user from sending commands to another user's instance, as it's using a standard TCP port on the machine.
Also, it means the users must agree on which port each of them uses, which might be tedious.
It seems that a solution to both issues would be to allow using unix sockets, which are basically sockets but path-based, supporting file permissions. It seems that using a local file in the user's home directory would naturally propagate that directory's permissions, and avoid conflicts.
The text was updated successfully, but these errors were encountered: