Unmounting bind-mounts keeps files accessible

[dany74q]

Description

When umount-ing a host bind-mount, the syscalls succeeds and the mount is no longer visible in mountinfo, but the bind-mounted files are still accessible w/ their original contents.

Steps to reproduce

oci spec with CAP_SYS_ADMIN and a custom bind mount:

{"ociVersion":"1.0.0","process":{"terminal":true,"user":{"uid":0,"gid":0},"args":["sh"],"env":["PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin","TERM=xterm"],"cwd":"/","capabilities":{"bounding":["CAP_SYS_ADMIN"],"effective":["CAP_SYS_ADMIN"],"inheritable":["CAP_SYS_ADMIN"],"permitted":["CAP_SYS_ADMIN"],"ambient":["CAP_SYS_ADMIN"]},"noNewPrivileges":true},"root":{"path":"rootfs","readonly":true},"hostname":"gvisor","mounts":[{"destination":"/proc","type":"proc","source":"proc"},{"destination":"/sys","type":"sysfs","source":"sysfs","options":["nosuid","noexec","nodev","ro"]},{"destination":"/dev","type":"tmpfs","source":"tmpfs"},{"destination":"/tmp/bind-mount","type":"bind","source":"/tmp/bind-mount","options":["bind"]}],"linux":{"resources":{"devices":[{"allow":false,"access":"rwm"}]},"namespaces":[{"type":"pid"},{"type":"mount"},{"type":"ipc"},{"type":"uts"},{"type":"cgroup"},{"type":"network"}]}}

echo bind-mount > /tmp/bind-mount
runsc run test

$ mount | grep bind-mount
none on /tmp/bind-mount type 9p (rw,trans=fd,rfdno=4,wfdno=4,aname=/,dfltuid=4294967294,dfltgid=4294967294,dcache=1000,cache=remote_revalidating,disable_fifo_open,overlayfs_stale_read,directfs)

$ cat /tmp/bind-mount
bind-mount

$ umount /tmp/bind-mount && echo 1
1

$ mount | grep -q bind-mount || echo not found
not found

$ cat /tmp/bind-mount
bind-mount

runsc version

runsc version release-20260302.0
spec: 1.1.0-rc.1

uname

Linux 5c915a61b95b 6.12.69-linuxkit #1 SMP Mon Feb 16 11:19:06 UTC 2026 aarch64 aarch64 aarch64 GNU/Linux

[dany74q]

Small ping, maybe @ayushr2 / @fvoznika ?

[ayushr2]

The issue here requires fixing which is a bit more involved. When you invoke unmount, we do successfully unmount from gVisor's VFS layer. But the gofer process holds the rootfs and it bind mounts all bind-mounts-in-the-OCI-spec into the rootfs directly. So we need to add logic to propagate the unmount operation into the gofer process when a gofer client is un-mounted. It requires adding a new RPC to lisafs.

[fvoznika]

This is what's happening...the gofer process is pivot-rooted into a directory that must have only container accessible files. For simplicity, all bind volumes are mounted into a single directory tree that matches the rootfs structure for the container. This happens in the host file system. Then, inside gVisor, the same bind mounts are created to emulate the same configuration inside the sandbox.

When you umount the volume, the gVisor volume is unmounted, but the files/directories still exist in the underlying file system. Therefore, if you look at the directory again, you'll see them.

There are a few ways to handle this:

1. Propagate the umount operation to the host: this requires adding a new LisaFS message to the gofer to unmount the volume in the host. And allow the Gofer to call umount.
2. Pop up root FS dir: currently the root FS in the host is created like this:

rootfs   ==> Gofer `pivot-root` here
    |
    + dir1
    + vol-mount-1
        |
        + vol-mount-2 

We could change it to look like this:

gofer-dir   ==> Gofer `pivot-root` here
    |
    + rootfs
        |
        + dir1
    + vol-mount-1
    + vol-mount-2 

Then gVisor mounts vol-mount-1 and vol-mount-2 inside the root FS, similar to how we do today. This would make the files appear in the correct place inside the sandbox. But the files would not be visible after the gVisor mount is removed.

3. Make umount create whiteouts in the upper overlay layer (this only works if rootfs is using overlayfs)

I personally prefer #2. None are simple changes to make. Normally, external mounts are not something that gets unmounted frequently. Is this something you bumped into or do you have a real need to do it?

[ayushr2]

Agree with the preference for #2.

[dany74q]

Thanks for the detailed analysis ! I like the second option as well.

I've tackled this while building a supervisor daemon that spawns some entrypoint in a new mount ns, trying to make some infra mounts inaccessible for it - in my case I need both to run in the container.

Not too common of a case I'd assume, but still it would be nice to align the behavior to standard linux.