You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Consider a user who does not have root access is using rootless podman. They create containers with volume mount points to persist data in the host environment. These containers may create folders and files using subids, and the user can if needed delete or modify these files using podman unshare. This works nicely.
However, it may happen with a wrong command that our user uses the wrong folder as mountpoint, for example the root of the home folder (with a dangerous $PWD). Then the container may feel at home in this mountpoint and start a recursive chown in the whole home folder - including .local/share/containers and .config/containers !
When this happens, all podman commands stop working, including podman unshare, which means our user becomes entirely stuck.
Suggest potential solution
A solution I imagine would be to be able to configure podman, on a system-level, with a blacklist of folders in the system that when given as mount points to a --volume option, would trigger a warning and/or an error.
Typically, one would want to blacklist the home folder of all users, but also maybe / and .local/share/containers or .config/containers.
Have you considered any alternatives?
Provide a podman command that could fix the initial scenario, and that would work even without access to .local/share/containers or .config/containers?
Additional context
Add any other context or screenshots about the feature request here.
The text was updated successfully, but these errors were encountered:
Feature request description
Consider a user who does not have root access is using rootless podman. They create containers with volume mount points to persist data in the host environment. These containers may create folders and files using subids, and the user can if needed delete or modify these files using
podman unshare
. This works nicely.However, it may happen with a wrong command that our user uses the wrong folder as mountpoint, for example the root of the home folder (with a dangerous
$PWD
). Then the container may feel at home in this mountpoint and start a recursivechown
in the whole home folder - including.local/share/containers
and.config/containers
!When this happens, all podman commands stop working, including
podman unshare
, which means our user becomes entirely stuck.Suggest potential solution
A solution I imagine would be to be able to configure podman, on a system-level, with a blacklist of folders in the system that when given as mount points to a
--volume
option, would trigger a warning and/or an error.Typically, one would want to blacklist the home folder of all users, but also maybe
/
and.local/share/containers
or.config/containers
.Have you considered any alternatives?
Provide a podman command that could fix the initial scenario, and that would work even without access to
.local/share/containers
or.config/containers
?Additional context
Add any other context or screenshots about the feature request here.
The text was updated successfully, but these errors were encountered: