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.
关于作者
Daniel Walsh has worked in the computer security field for over 30 years. Dan is a Senior Distinguished Engineer at Red Hat. He joined Red Hat in August 2001. Dan leads the Red Hat Container Engineering team since August 2013, but has been working on container technology for several years.
Dan helped developed sVirt, Secure Virtualization as well as the SELinux Sandbox back in RHEL6 an early desktop container tool. Previously, Dan worked Netect/Bindview's on Vulnerability Assessment Products and at Digital Equipment Corporation working on the Athena Project, AltaVista Firewall/Tunnel (VPN) Products. Dan has a BA in Mathematics from the College of the Holy Cross and a MS in Computer Science from Worcester Polytechnic Institute.
产品
工具
试用购买与出售
沟通
关于红帽
我们是世界领先的企业开源解决方案供应商,提供包括 Linux、云、容器和 Kubernetes。我们致力于提供经过安全强化的解决方案,从核心数据中心到网络边缘,让企业能够更轻松地跨平台和环境运营。