Getting into the weeds with Buildah: The buildah unshare command

Sometimes users wonder about the constraints of rootless mode for Buildah and Podman container engines. With rootless mode, we are pushing the boundaries of what a non-privileged user can do. One of my jobs is working with the kernel teams and file system teams to make rootless better. In this article, I explain why mounting images is more difficult in rootless mode.

[ You might also like: Balancing Linux security with usability ]

Rootless mounting

A normal user cannot mount a filesystem unless they're in a user namespace along with its own mount namespace. A mount namespace allows processes inside of it to mount file systems that are not seen by the host mount namespace. This kernel constraint protects the host operating system from potential attacks where a user could mount content over /tmp or even in their home directory and then trick other processes on the system or administrators to use the mount points.

Once the user’s process joins the user namespace and the new mount namespace, the kernel only allows certain file systems to be mounted. As of this writing, the kernel allows the sysfs, procfs, tmpfs, bind mount, and fuse file systems. We recently got a patch into the upstream kernel to support overlay file systems, which will be a big improvement, but currently, most distributions do not have this support. I would love to get NFS support, but there are security risks with this. Hopefully, the kernel will fix these issues, and eventually, it will be supported.

Rootless container engines like Podman and Buildah automatically create their own user namespace and mount namespace when they execute. When the container engine process exits, the user and mount namespaces go away, and the user process goes back to the host mount namespace. At this point, the mounts created while running the tools are no longer visible to or usable by other processes on the host.

Why is this important?

One of the cool features of Buildah is to allow users to get access to the low-level semantics of container building. Most container image builders are stuck with only one way of building containers—basically using Containerfiles or Dockerfiles. Buildah bud supports building with these files. Buildah also allows users to build containers using low-level primitives. Users can use it to create a directory,  populate the directory with content, create an image, and push it to a registry.

# ctr=$(buildah from scratch)
# mnt=$buildah mount $ctr)
# dnf -y --installroot $mnt httpd 
# buildah config --entrypoint .... $ctr
# buildah commit $ctr IMAGE
# buildah push IMAGE REGISTRY

This all works great when running as root, but when users attempt to run this in rootless mode, their scripts blow up.

$ mnt=$(buildah mount $ctr)
cannot mount using driver overlay in rootless mode. You need to run it in a `buildah unshare` session

The issue is mnt=$(buildah mount $ctr) refuses to mount the image with the overlay driver if you have not executed buildah unshare.

Taking a closer look

When you execute buildah commands, like bud and run, in rootless mode, the buildah command enters the user and mount namespaces. It mounts the container file system fine and runs the commands. When the command completes, buildah exits, causing the namespaces to be destroyed. When doing this with the mount command, the mounted file system was never seen in the host mount namespace. Buildah now checks for this situation and reports to the user that they have to issue a buildah unshare first.

buildah unshare

Buildah and Podman have a special command, unshare. This command creates and enters the user namespace without creating or interacting with a container. It is actually fairly interesting to explore this mode to fully understand what the user namespace is doing. Executing the buildah unshare command will run a shell command in the namespaces running as root in the user namespace. Now you can run any command, including the buildah commands described above. Since these commands are already in the namespaces, the buildah mount command will work the same as it does in rootful mode. Everything happens inside of the namespaces, and the user gets what they expect.

Now the user could take the commands listed above and create a shell script. This shell script is then executed directly with the buildah unshare command.

$ cat > buildahimage.sh < _EOF
ctr=$(buildah from scratch)
mnt=$buildah mount $ctr)
dnf -y --installroot $mnt httpd 
buildah config --entrypoint .... $ctr
buildah commit $ctr IMAGE
buildah push IMAGE REGISTRY
 < _EOF
chmod +x /buildahimage.sh
buildah unshare ./buildimage.sh

[ Getting started with containers? Check out this free course. Deploying containerized applications: A technical overview. ]

Wrap up

Sadly we can't fix everything within the kernel to give users the rootless experience they expect, mainly because of security concerns. But we can get pretty close. And of course, you can always work in rootful mode if you need additional features.