sudo in Dockerfile?

[nhooyr]

See #57 (comment)

[incizzle]

I agree with @sr229 the container should not be launching commands as sudo all the time.

[nhooyr]

@incizzle appreciate the input but could you elaborate on your reasoning why?

[incizzle]

I think @sr229 summed it up pretty well. I personally don't see running every command as sudo in this environment as a bad thing, but it doesn't instill good security practices & habits when this is transferred to other places.

[sr229]

This is how I see we're teaching people bad practices. They don't know linux, and they're learning via guides. If they decide to use Linux outside of Coder they won't know the concept behind sudo and permissions. We need to let them know "hey, you might need to run this specific command first before doing that", and this adds a certain familiarity of how the concept of permissions work.

We in turn, teach them how security usually works in Linux for beginners, and we give a sense of familiarity for other users. You don't see GCP giving you away a VM with a root account because you're expected to know about sudo and the concept of Linux security by permissions.

[frol]

Docker best-practices (“USER” section) describes how to do this.

As a side effect, running code-server as root will result in that the newly created files become owned by root, so soon enough user will end up with a project that cannot be modified from their regular user. To solve the permission issues, it is recommended to create a regular user and remap host UID & GID

[sr229]

I'm willing to reimplement the Dockerfile in the repo by basing off from my already existing image, should I get enough consensus that we should do usermode in this Dockerfile.

[NGTmeaty]

I think this ^^ is the best idea at the moment. May want to wait for a code owner to give their opinions.

The design issue here is, that you should not make any modifications to the docker container after it started up.
Being able to install some dev tools etc. in the VS Code terminal while using it is very bad practice, and as mentioned in #86, there should be a seperate container for each terminal, which has the project directory mounted into it, and also the container image of that individually spawned container should have the required build/dev tools for each language or project type.

That said, adding a USER statement to the dockerfile would break the possibility to use the terminal for anything like package installation.

[sr229]

@PhilsLab I don't think it should be as locked down as you need to on #86. However, I did provide a variant that does exactly that which works for OpenShift Online, but its pain to compensate for common use cases.

[incizzle]

@PhilsLab, In order to have a separate container for each dev environment, it would require a lot of recoding of the actual VS code online program. It sounds likes its gonna be very hard to implement but it is a cool idea.

[sr229]

Theia did support this kind of work (Remember Eclipse Che 7?), however, this would require substantial backend re-engineering which would increase the amount of difficulty per new VSCode release since it might not be interopable with each other

[kylecarbs]

You could just mount the projects and data-dir into your docker container on each start. Then you start where you were in a completely new environment.