Add option to set unix socket permissions

[Grimeton]

Hello,

when using the --socket option, I can tell code-server which socket to use, but not the permissions. At the moment the default permissions are 0755, which means that only the user is able to write to the socket while it's world readable...

When running together with a web server, it'd be nice if it could be set to 0770 and giving the group name/id so that a common group between web server and code-server would be possible.

Something like:

--socket /var/run/code-server.sock,0770,user,group
--socket /var/run/code-server.sock,0770,,group

Also, the server doesn't clean up the socket when it goes down and on a restart it errors out with address already in use...

I'm using workarounds at the moment, but it would be better if code-server could take care of it on its own.

[kylecarbs]

I'd agree with this. Setting users/groups seems a bit odd to me though. Is there an example of software you know that has this syntax?

[Grimeton]

Usually a program/system has a configuration file where these settings are defined in. As most of the socket related stuff is handled by systemd on a newer Linux system, the settings look something like this:

ListenStream=/run/snapd-snap.socket
SocketMode=0666
SocketUser=root
SocketGroup=root

You can also go with --socket-user --socket-group --socket-permissions if you prefer. This was just an idea I had, to keep it compact.

Cu

[nhooyr]

Can you put the socket in a directory with whatever perms you need?

[Grimeton]

What do you mean by that?

Like creating a socket and then point code-server to it?

It's still a listening socket, even if it's a Unix socket. So the server has to create it with everything that belongs to it.

Cu

[nhooyr]

Like creating a socket and then point code-server to it?

Create the directory for the socket and put whatever permissions you want on that directory. Then when starting code-server make the path for the socket be inside that directory.

See https://stackoverflow.com/a/21568011/4283659

[necmettin]

I'd agree with this. Setting users/groups seems a bit odd to me though. Is there an example of software you know that has this syntax?

php-fpm allows you to set socket's user, group, and permissions. Systemd itself (which runs pretty much every Linux service on a running host) allows you to set socket user, group, and permissions.

[nhooyr]

php-fpm allows you to set socket's user, group, and permissions. Systemd itself (which runs pretty much every Linux service on a running host) allows you to set socket user, group, and permissions.

To clarify, @kylecarbs is asking for examples regarding just the syntax, not whether socket permissions can be set in other software.

[nhooyr]

Going to close as I believe a directory with permission restrictions is enough. If not, please comment and I'll reopen.

[Grimeton]

It's a common thing. A UNIX socket is represented by a file on the file system and the only way to protect it is to change the owner, group and the mode. Not offering this option is a security nightmare.

No. A directory around it to protect it is not an option.

[nhooyr]

No. A directory around it to protect it is not an option.

Can you elaborate why not? I'm not hard set against it but given how easy it is to create a directory with whatever permissions you need, it's best we not add more options to code-server.

Either way I'll reopen and do a survey of what other modern servers do and we can go from there.

[Grimeton]

Well,

the (7) UNIX man page says:

Pathname socket ownership and permissions
       In the Linux implementation, pathname sockets honor the permissions of the directory they are in.  Creation of a new socket fails if the process does not have write and search (execute) permission on the directory in which the socket is created.

       On  Linux, connecting to a stream socket object requires write permission on that socket; sending a datagram to a datagram socket likewise requires write permission on that socket.  POSIX does not make any statement about the effect of the permissions on
       a socket file, and on some systems (e.g., older BSDs), the socket permissions are ignored.  Portable programs should not rely on this feature for security.

So this is a 50/50 thing. If this moves to a BSD before 4.2, then we could get into trouble, but other than that, it's just the way how a socket is made secure. I wonder if most people even know that some systems do not honor the file system permissions on UNIX sockets.

Cu

on Linux systems the file permissions are honored on the socket and as long as the connecting part is not able to