1.6. Special considerations for rootless containers
There are several considerations when running containers as a non-root user:
-
The path to the host container storage is different for root users (
/var/lib/containers/storage) and non-root users ($HOME/.local/share/containers/storage). - Users running rootless containers are given special permission to run as a range of user and group IDs on the host system. However, they have no root privileges to the operating system on the host.
-
If you change the
/etc/subuidor/etc/subgidmanually, you have to run thepodman system migratecommand to allow the new changes to be applied. -
If you need to configure your rootless container environment, create configuration files in your home directory (
$HOME/.config/containers). Configuration files includestorage.conf(for configuring storage) andcontainers.conf(for a variety of container settings). You could also create aregistries.conffile to identify container registries that are available when you use Podman to pull, search, or run images. There are some system features you cannot change without root privileges. For example, you cannot change the system clock by setting a
SYS_TIMEcapability inside a container and running the network time service (ntpd). You have to run that container as root, bypassing your rootless container environment and using the root user’s environment. For example:# podman run -d --cap-add SYS_TIME ntpdNote that this example allows
ntpdto adjust time for the entire system, and not just within the container.A rootless container cannot access a port numbered less than 1024. Inside the rootless container namespace it can, for example, start a service that exposes port 80 from an httpd service from the container, but it is not accessible outside of the namespace:
$ podman run -d httpdHowever, a container would need root privileges, using the root user’s container environment, to expose that port to the host system:
# podman run -d -p 80:80 httpdThe administrator of a workstation can allow users to expose services on ports numbered lower than 1024, but they should understand the security implications. A regular user could, for example, run a web server on the official port 80 and make external users believe that it was configured by the administrator. This is acceptable on a workstation for testing, but might not be a good idea on a network-accessible development server, and definitely should not be done on production servers. To allow users to bind to ports down to port 80 run the following command:
# echo 80 > /proc/sys/net/ipv4/ip_unprivileged_port_start