[Bug]: Can't start 2 instances of code-server `4.14.0` for separate users

[bilogic]

Is there an existing issue for this?

• I have searched the existing issues

OS/Web Information

• Web Browser: Chrome
• Local OS: Ubuntu
• Remote OS: Windows
• Remote Architecture: amd64
• code-server --version: 4.14.0

Steps to Reproduce

1. Run /usr/bin/code-server for user 1 - ok
2. Run /usr/bin/code-server for user 2 - fails with the following

Expected

Both instances should start

Actual

2nd instance fails to start

Logs

2nd instance tries to open the same file

[2023-06-19T16:15:12.625Z] info code-server 4.14.0 9955cd9
[2023-06-19T16:15:12.626Z] info Using user-data-dir ~/code-server/user
[2023-06-19T16:15:12.629Z] error EPERM: operation not permitted, unlink '/tmp/code-server-ipc.sock'

Screenshot/Video

No response

Does this issue happen in VS Code or GitHub Codespaces?

• I cannot reproduce this in VS Code.
• I cannot reproduce this in GitHub Codespaces.

Are you accessing code-server over HTTPS?

• I am using HTTPS.

Notes

It seems that every instance is trying to write to /tmp/code-server-ipc.sock, this was not the case in 4.13.0. Is there a way to specify an alternate socket file for each instance?

[Fmstrat]

Having the same issue, this totally bricked our shared development environment.

EDIT For anyone else who ends up here, a downgrade worked for my environment.

[code-asher]

Before we were writing to a file instead of a socket and I think we must have been ignoring write errors but with the new system we do not. We may want to catch and warn about errors rather than hard failing. Additionally we should use a unique socket path per user. CC @sleexyz in case you have interest in fixing this, otherwise I believe I will have time next week.

[sleexyz]

@code-asher Ah darn, I'll take a stab rn.

[mirekphd]

our shared development environment.

Having two users (even if there are just two of them) access the same data folder is a rather week form of isolation. It's not just usability, but a security issue as well. Such multi-tenancy requires proper storage isolation, e.g. with PVCs in k8s.

[Fmstrat]

our shared development environment.

Having two users (even if there are just two of them) access the same data folder is a rather week form of isolation. It's not just usability, but a security issue as well. Such multi-tenancy requires proper storage isolation, e.g. with PVCs in k8s.

At what point did I say a shared data folder? This bug is literally about a lock file with the same filename (in tmp) being used for all users regardless of data directory.

[mirekphd]

our shared development environment.

Having two users (even if there are just two of them) access the same data folder is a rather week form of isolation. It's not just usability, but a security issue as well. Such multi-tenancy requires proper storage isolation, e.g. with PVCs in k8s.

At what point did I say a shared data folder? This bug is literally about a lock file with the same filename (in tmp) being used for all users regardless of data directory.

It's enough to share /tmp (which admittedly is not a "data" folder, you got me there) from each user namespace between multiple users to let users overwrite each other's settings (maliciously or unwittingly) in such browser-based IDEs.

[bilogic]

@mirekphd

If you are facing an issue, please provide logs
If you think the solution is wrongly implemented, please comment on the PR #6278, not here