Allow alternative install sites for devspacehelper/proxy commands

[kevin-hanselman]

Is your feature request related to a problem?

Due to a combination of container user and filesystem permissions, /usr/local/bin and/or /tmp may not be writable, and the devspace SSH key may not be readable by the container user.

For example, take any image from the Jupyter Docker Stacks project: It expects to own both /usr/local/bin and /tmp. The images support running as both root and a non-privileged user, but both cases don't work with devspace:

• When running the container as a non-privileged user (a widely accepted--or enforced--security best practice), the injected devspace tools cannot write to /usr/local/bin because it is owned by root. This isn't limited to just the Jupyter images. For example, the base Ubuntu image restricts access to /usr/local/bin as well.
• When running the container as root, the devspace tools can write to /usr/local/bin, but the SSH key it creates for the proxy commands cannot be opened by the non-privileged user that runs the Jupyter UI (where a developer could work).

One could argue two things:

• Hosting an IDE in your k8s workload stretches what devspace was built for.
• These Jupyter images represent a corner case (i.e. dual user startup) that's not worth supporting.

But I think adding the ability to configuring these locations is a sensible solution that doesn't harm the default UX of devspace.

Which solution do you suggest?

Add one or more configuration options to control where the proxy commands and SSH key get installed. For example, one could configure devspace to use ~/.local/bin for proxy commands and ~/.cache for the SSH key.

Which alternative solutions exist?

Add a configuration option to set the permissions and owner of the files devspace wants to create. At face value, this seems a bit more brute force than configuring the locations of the files, but maybe I'm missing something.

[lizardruss]

@kevin-hanselman Thanks for opening this issue. We'll discuss and decide if we will prioritize this issue.

In the past I've worked around such limitations by creating my own image and modifying the needed file permissions, but that's not very convenient.

I think the current assumption is that /usr/local/bin will be on the $PATH for the majority of containers, so changing this location may lead to issues. It'll take some extensive testing to see how heavily things depend on that assumption.

Hope to have an answer on whether we'll work on this soon.

[lizardruss]

@kevin-hanselman Could you provide more details on the DevSpace features you're using with these Jupyter images? I'm wondering if disabling the features that need SSH and the devspacehelper would be a sensible workaround.

[kevin-hanselman]

@kevin-hanselman Could you provide more details on the DevSpace features you're using with these Jupyter images? I'm wondering if disabling the features that need SSH and the devspacehelper would be a sensible workaround.

@lizardruss Unfortunately my main interest in DevSpace is to use the SSH and command proxy features.