`gopls` cannot run becuase it uses a custom user

[WhyNotHugo]

gopls uses a custom user inside the container. This user will never match the uid of the user running the container on the host (the uid of the containerised users is mapped to an uid in the host in the range definedin /etc/subuid).

Since my projects are in my $HOME, the user inside gopls can't access it, and fails with Permission denied. It's only really possible to work on project that are world readable.

I'm looking at #63, and I don't think this change really makes sense; it you use root inside the container, that root user will have the uid of the user running docker / podman on the host. #63 would only make sense if you're running docker/podman as root, but that doesn't seem like a very sensible thing to do, especially for LSPs. I think if you do so, it'd be possible for the LSP to read-write files on the host that are only readable by root.

I think it's probably best to revert #63, and discourage users from running the LSP containers as root in the first place.

[erikreinert]

Sorry for the delay on this - the intent on making the change was to have to roll-forward and iterate. It was going to be difficult to catch all the edge cases (which I 100% agree with you) so I appreciate you noting it.

I'd like to solve this problem but haven't had much time to revisit it (also haven't been using Go much). We have a project in Go that I can debug over the weekend and report back with more. We will get this fixed.

[erikreinert]

I recently made some changes to the gopls server - would you mind checking and seeing if this is still an issue? Thank you!

[erikreinert]

Just want to follow up on this - we are getting reports this should be working now. So I will leave this open a bit longer before closing.

[WhyNotHugo]

Sorry, haven't had the time to test it out properly. I moved to sandboxing gopls via bubblewrap (which uses the system installation instead of an image), so haven't had a chance to set this up and confirm the fix.

If other reported fixed, I'm fine with closing this.

[WhyNotHugo]

Generally, I think the situation is fragile because some people run docker as root, and others as $USER, so expectations on $UID mappings and alike can conflict.

[erikreinert]

I don't disagree with you at all and I think trying to find the best middle ground is as close as we may be able to get with these types of language servers. This is simply a caveat to using containers to solving this problem.

Anything made with vscode-language-server framework seems to work effortlessly. However when it requires the OS, etc these mechanisms fall short.

There is support for Nix (and other backends) in the future which eliminates containers entirely and may be a better solution. Here is the existing PR: lspcontainers/lspcontainers.nvim#91

Going to close this for now and we can keep iterating! Thank you!