Hello,
I'm writing a feature which requires writing configuration files to the home directory of the user within the container.
Looking at the source code of existing implemented features as a reference, such as the anaconda feature, I encountered code such as the following, which has specific logic to determine the user (and thus the home directory location).
I wasn't able to find specific documentation in the proposal on a "contract" for feature developers; with details on a USERNAME environment variable being provided when executing the install.sh script. Furthermore, use of "magical" users such as automatic, auto, vscode, node, codespace or other (via /etc/passwd) to aid in the determination behaviour is something I wouldn't want to have to repeat in authoring my features.
Furthermore, the reliance on having one of these user exist in a given base image is tenuous and makes this logic quite fragile (and smelly).
Therefore I propose a better and surprisingly much simpler solution, inspired in part by how the vagrant shell provisioner works, as follows:
The process which is executing the install.sh script, has access to the given devcontainer.json file, which defines a remoteUser and thus can be used to provide the USERNAME environment variable to the script; sort of like a docker build argument, which would remove the need to have to infer the correct user.
Since the feature install.sh script is typically executed as root, unless the base image switches the user, files installed to the home directory need to be chowned to make the files accessible to the user when the dev container is running. This can be solved by having an optional devcontainer-feature.json property, such as installAs, which is an enum type with values of root or remoteUser. When remoteUser is provided, install.sh is executed in the context of the user provided by the remoteUser property. This is similar in concept to how the privileged setting of the vagrant shell provisioner alters the context. This does place a limitation on what the install.sh script can do, so authors should include an assertion for root if required for proper execution.
To aid troubleshooting, since the onus is on the devcontainer.json author to ensure alignment of the user(s) contained in the base image and the remoteUser provided, a check should be performed before installing features, to assert that the given remoteUser exists and a nice helpful message if it doesn't.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4