Fail to create tls-proxy for the second process.

[huangy10]

• Web Browser: Chrome
• Local OS: Windows 10
• Remote OS: Ubuntu 16.04
• Remote Architecture: x86_64
• code-server --version: 3.5.0

When running two process in the same server by two different users, the second one won't work and gives the following error:

discarding socket connection: EACCES: permission denied, unlink '/tmp/code-server/tls-proxy'

Notice that the tls-proxy is created by the first process. Obviously, it is not accessible by the second process.

After a little research, I find out that this bug is caused by a logic error in socket.ts, line 94.

public async findFreeSocketPath(basePath: string, maxTries = 100): Promise<string> {
    let i = 0
    let path = basePath
    while ((await canConnect(path)) && i < maxTries) { // the line with bug
      path = `${basePath}-${++i}`
    }
    return path
  }

which should be

public async findFreeSocketPath(basePath: string, maxTries = 100): Promise<string> {
    let i = 0
    let path = basePath
    while (!(await canConnect(path)) && i < maxTries) { // fix the bug
      path = `${basePath}-${++i}`
    }
    return path
  }

When the current path is not accessible, then try next one.

What is interesting is that when the second user is root, then canConnect returns true in the original code, a new socket file tls-proxy-1 is created successfully. So that I think the code here should be further modified. We should check if there is a file in path. If there is a file here, we should not use this even it is accessible unless the current user is not root.

---

There is another problem here: the directory /tmp/code-server is created and owned by the first user, which means this directory is not writable for the second user, so the new socket file tls-proxy-1 cannot be created. I have to manually change the permissions of the directory to make everything works.

---

Ok I forget one last thing. When I fix every as discribed above, the web client still shows nothing. After checking chrome console, a 404 error occurs for file in path code-server/release-standalone/dist/pages/pages/vscode.js. Notice that there are two pages here, while the structure of the dist folder is dist/pages/vscode.js. I have to manually create another pages folder, and copy everything else into it.

finally, everything works fine.

[code-asher]

Nice catch! One workaround is to handle TLS in a reverse proxy, then code-server won't have to create the TLS proxy. Maybe we should use a path in the user's data directory instead? Then we won't have any permission issues or users stepping on other users' toes. Or we could use a random path in /tmp which would do the same thing (this is how VS Code does it). I'm not sure about the double pages directory though. The HTML that loads that script is: ``` <script data-cfasync="false" src="{{CS_STATIC_BASE}}/dist/pages/vscode.js"></script> ``` So it seems like it shouldn't be possible. I'm not able to replicate with our 3.5.0 release but I'll keep an eye out for it. It might be a bug in the build process that doesn't occur in CI.

[huangy10]

I try to replicate this time and it is gone now. But I find a very very interesting thing!

I wrap my url to the code-server with nativefier to create a standalone native application in Win10. Within the built-in console in the wrapped app, I run a new code-server process on my remote server on a different port. Normally it should print some logs, and I should open a new chrome page and visit the new port. However, this time a new window of the native app is automatically created, which lead me to the code-server service on the new port!

[huangy10]

Now everything is crazy. As I said in the last comment, running code-server within the console of the native application wrapped by nativefier, a new window is displayed as ask for password. Since the new code-server command is simply ./code-server --bind-addr 0.0.0.0:5010 ., it means the same default configuration file ~/.config/code-server/.config.yaml is used. Thus I input the password defined in that file, and the authentication succeeds.

Next, I want to replicate this, so I close the new window, and run the code-server in the native app again. This time a new window is created but nothing is displayed. What is worst is that the original code-server process is corrupted!

I check the log of the first code-server process, and it says:

(node:59077) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 error listeners added to [ChildProcess]. Use emitter.setMaxListeners() to increase limit

---

To conclude everything above: If two code-servers are started by the same user, then the second process may still try to use the tls-proxy created by the first process (note that here I fix the bug mentioned above and use the code-server binary built by myself), which may corrupt everything. Notice that the tls-proxy file is indeed accessible by the second process, but the connection number is limitted.

---

When I say 'the original code-server process is corrupted', I mean that even if I stop all other code-server process, and the tls-proxy does not exist (It is not manually deleted, I think it is deleted by other code-server process on exit). The original code-server process still holds some kind of handler to that deleted tls-proxy file. So when new connection comes, instead of creating a new tls-proxy, it tries to connect the deleted socket file, which will certainly fail.