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
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.
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:
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.
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.
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.
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.
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.
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
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.
I'm trying to run multiple instances of code-server on one development server. Instead of using ports, it seems cleaner to give each developer their own socket. I tried to follow your instructions and created /var/run/code-server owned by user/group www-data:www-data. I add the user that code-server runs under to the www-data group, however when I run code-server, I get a permission denied error. My goal is to use nginx to proxy each user's subdomain to the unix socket connected to the code-server for their home folder. Any insight you can provide would be really appreciated. Thank you!
I run code-server as user 1000, so I can get same experience as my code-oss. However, when trying to rev proxy code-server using NGINX, which is running as user http, I got permission errors.
As the socket file is owned by user 1000 and has 755 permission, any other user have no chance to connect it because they lack the write permission.
It's hard to workaround since the socket is recreated every time code-server starts.
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.
In case you're using reverse proxy web server (e.g. NGINX) you need to ensure that NGINX can write to this socket.
Most web server bundled with distros are running with www-data, apache, nobody, ... user.
The socket created by code-server has default permission 0755 (owner has write permission) with the user:group of the owner (who run it).
This mean most web server can not write to the code-server socket and the proxy would never work.
In my use case, I just need some option to set the socket permission to 0777 so that my NGINX can write to this socket and the proxy just works.
Activity
kylecarbs commentedon Apr 14, 2020
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 commentedon Apr 15, 2020
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 commentedon Apr 17, 2020
Can you put the socket in a directory with whatever perms you need?
Grimeton commentedon Apr 18, 2020
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 commentedon Apr 19, 2020
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 commentedon Apr 25, 2020
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 commentedon Apr 27, 2020
To clarify, @kylecarbs is asking for examples regarding just the syntax, not whether socket permissions can be set in other software.
nhooyr commentedon Apr 28, 2020
Going to close as I believe a directory with permission restrictions is enough. If not, please comment and I'll reopen.
Grimeton commentedon Apr 30, 2020
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 commentedon May 1, 2020
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 commentedon May 1, 2020
Well,
the (7) UNIX man page says:
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
schristm commentedon Jun 12, 2020
I'm trying to run multiple instances of code-server on one development server. Instead of using ports, it seems cleaner to give each developer their own socket. I tried to follow your instructions and created /var/run/code-server owned by user/group www-data:www-data. I add the user that code-server runs under to the www-data group, however when I run code-server, I get a permission denied error. My goal is to use nginx to proxy each user's subdomain to the unix socket connected to the code-server for their home folder. Any insight you can provide would be really appreciated. Thank you!
5 remaining items
stale commentedon Oct 26, 2021
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no activity occurs in the next 5 days.
TechCiel commentedon Feb 17, 2022
This feature seems necessary in my case.
I run code-server as user 1000, so I can get same experience as my code-oss. However, when trying to rev proxy code-server using NGINX, which is running as user http, I got permission errors.
As the socket file is owned by user 1000 and has 755 permission, any other user have no chance to connect it because they lack the write permission.
It's hard to workaround since the socket is recreated every time code-server starts.
Sorry for any disturbance.
rtsp commentedon Feb 17, 2022
In case you're using reverse proxy web server (e.g. NGINX) you need to ensure that NGINX can write to this socket.
Most web server bundled with distros are running with
www-data,apache,nobody, ... user.The socket created by code-server has default permission 0755 (owner has write permission) with the user:group of the owner (who run it).
This mean most web server can not write to the code-server socket and the proxy would never work.
In my use case, I just need some option to set the socket permission to 0777 so that my NGINX can write to this socket and the proxy just works.