Add initializeCommand support to features

[hellodword]

initializeCommand is a very useful lifecycle hook and it's the only way I found to run commands on the host machine, and devcontainer-feature.json does not support it, could it been supported in the future?

[samruddhikhandale]

Hi 👋

Thanks for bringing this up, when lifecycle hooks were first introduced for Features, initializeCommand was intentionally omitted as it required detailed discussions on a secure design (due to its ability to run commands on host machine). It would be great to start that discussion again, moving it to the spec repository.

[hellodword]

a secure design (due to its ability to run commands on host machine)

Totally agree, how about this:

devcontainer-feature.json keeps the ability of using initializeCommand, but requires an explicit declaration with a reserved option from the top level (generally .devcontainer/devcontainer.json).

For example:

"features": {
    "somefeature": {
        "allowToRunInitializeCommand": true
    }
}

Not that good, I believe there'll better solutions, but I think keeps the ability of using initializeCommand is really great

[devrite]

Such a feature would also be helpful in implementing my use case with minimal user interaction and re-usability through devcontainer-features.

My use-case: I need host user groups and ids to match them inside the container similar to common-tools for the remote user.

Regarding security, afaik:

• Features can request privileged
• Features can request host mount points
• Features can request caps and sec-opts
• Features can access workspace folder data.

If I were a malicious feature I would be able to do everything I need to escape the container or leak host info already. It would be more of a dev protection to not accidentally modify the host. So more a safety than security feature to prevent that. But if a feature decides to use any of the above settings it already must be sure to not leak or damage the host system by accident too.

Current implementation:

• initialzeCommand + onCreate/postCreate,...

Alternative workarounds:

• Init script or user var and replace postCreate with feature.
• Compose service dependencies with volumes (bind to ws or shared volume).
• Command hook script (overriding the the container executable path).
• Use a permanent mountpoint (e.g., request mount point for host info to <...some devcontainer/feautre/path). This could leak info longer than actually needed.

Solutions improving my usecase:

• The user can run command substitutions for env, options, ... to fill the values: $(cat .,..). Which can be filled with an overrideable default.
• Having an initializeHook as requested (Possibly overriden by the user or disabled on default).
• Temporary mounts (e,g. copying files to a volume or path the feature has access in the container) and is auto cleared.
• Any other way to request host info or is available on default.

Edit: Also a setting if after completion a container restart is required would be nice.

Best Regards,

Markus

[devrite]

As a reference I know implemented my example use case how I am currently able to achieve it: https://github.com/AIT-Assistive-Autonomous-Systems/devcontainer_features/tree/main/src/add-groups