Modify container after creation

[nathan-rabet]

The needs

Users need the flexibility to modify the capabilities and privileged status of an existing Exegol container without requiring its deletion and recreation. This is important as requirements for container permissions might change over time (e.g: a pentester may need to bind to a port below 1024, even during a web audit. This requires higher capabilities compared to an unprivileged container), and recreating a container is disruptive (loss of data/configuration).

Description

Currently, the Exegol wrapper allows specifying container capabilities (--cap) and the privileged flag (--privileged) during the initial container creation.

However, if these parameters are provided when starting an existing container, they are silently ignored by the wrapper. The following warning message is logged:

These parameters (XXX) have been entered although the container already exists, they will not be taken into account.

Alternatives

The current workaround is to delete the existing container and create a new one with the desired capabilities or privileged status. However, this is disruptive as it removes data and configurations within the container.

Alternative approaches for implementing the feature could include:

• Allowing exegol start to detect capability/privileged changes and apply them,
• Introducing a new command, (e.g., exegol update-container < --caps ... | --privileged | --unprivileged >), specifically designed for modifying settings of an existing container. This might be clearer than overloading start.

Additional context

This limitation reduces the flexibility of managing Exegol environments. Users are currently forced into a destructive workflow (recreation) if their capability needs change after initial setup. The warning message accurately reflects the current state but highlights the need for this functionality.

Implementing this feature would significantly improve the usability and flexibility of Exegol for users whose permission requirements evolve.

[ShutdownRepo]

Agreed 100%
However, we're not the ones preventing this... That's a Docker limitation and we can't do anything about it, sadly..
We could, however, make up for that by implementing a new feature that would allow for a new container to be created, your old container's data moved in the new one, and the old container be removed. This managed feature is in our roadmap, and it should help a lot with what you're describing.

[nathan-rabet]

Sorry I maybe mismatched the terms container and image in Exegol, but the idea is that even when your "Exegol instance" is in the "Stopped" state, it's currently impossible to update capabilities for the following startups.

[Dramelac]

We are aware of the problem, it's been identified for a long time and yes it's a limitation of docker itself.
Once a container has been created, even when it's stopped, it can NOT be modified. Docker doesn't allow this. Why exactly I don't know, but it's not possible.

However, as @ShutdownRepo said, we have an idea of how to solve this problem with a workaround, it's in the exegol roadmap.

Stay tuned ;)

[Dramelac]

If you don't believe me, you can look at the docker documentation, the configuration of a container can't be updated.
Only resource consumption limitation parameters, but that's all and that's not enough.
https://docs.docker.com/reference/cli/docker/container/update/