How to Use onCreateCommand with Root Permissions in VSCode Dev Containers

[sikso1892]

When using devcontainer in VSCode, I am facing an issue with the following scenario:

In the image, I configure the onCreateCommand to execute commands requiring root privileges, such as:

onCreateCommand: apt-get update && apt-get install {dev.packages etc. gdb ...}

However, the final user in the container is not root, but something like appuser. For this reason, I set the following configurations in devcontainer.json:

"containerUser": "root",
"remoteUser": "appuser"

Despite these settings, the commands in onCreateCommand are still executed as appuser, resulting in permission errors.

My Goal:

I want to execute the onCreateCommand as root during the container's initialization phase and then switch back to appuser afterward for development purposes.

Key Considerations:

• I do not want to use root as the final user in the container.
• Using root as the container user can cause issues, such as files created within the dev container being owned by root, which complicates file handling outside the container.

Question:

Does anyone have a good solution or best practice to achieve this? Ideally, I want the container to start as root during initialization and then automatically switch to appuser afterward. Any insights or advice would be greatly appreciated!

[chrmarti]

You could install the packages using a Dockerfile. That has the advantage of using Docker's layer cache.

If you have to use onCreateCommand for some reason, you could use sudo by configuring it to work without password (our images come with it preconfigured this way).

[sikso1892]

I understand the solution of modifying the Dockerfile, but I would prefer to base the development container on the deployment image's Dockerfile. My main concern is that I don't want to increase the size of the deployment image by adding development-specific dependencies.

As you mentioned, creating a separate development Dockerfile and installing the necessary packages there is one solution, but I would prefer not to take that approach.

If modifying the image is unavoidable, I think granting none-password sudo privileges as you suggested would be the best solution.

Thank you! 🙇🏻‍♂️🙇🏻‍♂️