Description
During normal lifetime of a compose job, the capabilities as defined in the yaml file are fine. However, inital setup might need temporary additional capabilities, especially when not running the container as root. For example, assuming cap-drop: all is set in the yaml file.
A container has a volume mounted, and is not run as root. For example volume: myvolume:/home/user/.config (ignore the poor choice for the example). By default, running this container, will volume-mount things as root. So for bootstrapping purposes, one needs to run:
docker compose run --user root mycontainer chown user:user -R /home/user and maybe docker compose run --user root mycontainer chgrp g+w -R /home/user. Both these operations require additional capabilities. While one can (temporary) add CAP_CHOWN and CAP_FOWNER, it requires manual work on the yaml file.
This could easily be solved by being able to do:
docker compose run --cap-add CAP_CHOWN --user root mycontainer chown user:user -R /home/user
docker compose run --cap-add CAP_FOWNER --user root mycontainer chgrp g+w -R /home/user
While one can run the (not yet existing) container with plain docker, the container name might not be known yet, the volume name might not be known etc, so using this within the compose context is very important.
Description
During normal lifetime of a compose job, the capabilities as defined in the yaml file are fine. However, inital setup might need temporary additional capabilities, especially when not running the container as root. For example, assuming
cap-drop: allis set in the yaml file.A container has a volume mounted, and is not run as root. For example
volume: myvolume:/home/user/.config(ignore the poor choice for the example). By default, running this container, will volume-mount things as root. So for bootstrapping purposes, one needs to run:docker compose run --user root mycontainer chown user:user -R /home/userand maybedocker compose run --user root mycontainer chgrp g+w -R /home/user. Both these operations require additional capabilities. While one can (temporary) addCAP_CHOWNandCAP_FOWNER, it requires manual work on the yaml file.This could easily be solved by being able to do:
While one can run the (not yet existing) container with plain docker, the container name might not be known yet, the volume name might not be known etc, so using this within the compose context is very important.