Podman also gives us a really cool sub-command called top which lets us map the user on the container host to the user in the running container. Like before, you can research these further by typing man podman-run command. The command line options are -i (interactive) -d (detach) and -u (user) - combined, these options run the container in the background and specify that the containerized process should run as the user sync. When the kernel creates a running process inside of a container, the user namespace maps the user ID of the containerized processes to a different user ID outside of the container. That’s exactly what user namespaces facilitate. Stated another way, these two passwd files imply that we could have two sets of users-one set outside of the container, and one set inside of the container. The users in the /etc/passwd file on the Container Host are used for Podman, while the users in the /etc/passwd file in the Container Image are used in the running container. Third, in the above example, Podman is by definition outside of the container and runs as root or a regular user (fatherlinux), while inside the container bash runs as root or a regular user (sync). These are Unix traditions that will help explain root inside and outside of the container. Second, pay close attention to $ which implies our shell is running as a regular user, and # which implies our shell is running as root.

You can research these further by typing ‘man podman-run’ command. First, the command line options are -i (interactive) -t (terminal) and -u (user) - combined, these options give you an interactive terminal inside of the container, and specify that the containerized process should run as the user sync.

Let’s point out a few interesting things about the above example.

Docker run as root user