> On Apr 13, 2023, at 22:43, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > > On Fri, Apr 14, 2023 at 08:41:03AM +1000, NeilBrown wrote: > >> The path name that appears in /proc/mounts is the key that must be used >> to find and unmount a filesystem. When you do that "find"ing you are >> not looking up a name in a filesystem, you are looking up a key in the >> mount table. > > No. The path name in /proc/mounts is *NOT* a key - it's a best-effort > attempt to describe the mountpoint. Pathname resolution does not work > in terms of "the longest prefix is found and we handle the rest within > that filesystem". > >> We could, instead, create an api that is given a mount-id (first number >> in /proc/self/mountinfo) and unmounts that. Then /sbin/umount could >> read /proc/self/mountinfo, find the mount-id, and unmount it - all >> without ever doing path name lookup in the traditional sense. >> >> But I prefer your suggestion. LOOKUP_MOUNTPOINT could be renamed >> LOOKUP_CACHED, and it only finds paths that are in the dcache, never >> revalidates, at most performs simple permission checks based on cached >> content. > > umount /proc/self/fd/42/barf/something > > Discuss. > > OTON, umount-by-mount-id is an interesting idea, but we'll need to decide > what would the right permissions be for it. > > But please, lose the "mount table is a mapping from path prefix to filesystem" > notion - it really, really is not. IIRC, there are systems that work that way, > but it's nowhere near the semantics used by any Unices, all variants of Linux > included. We already have support for directory file descriptors when mounting with move_mount(). Why not add a umountat() with similar support for the unmount side? Then add a syscall to allow users with (e.g.) the CAP_DAC_OVERRIDE privilege to convert the mount-id into an O_PATH file descriptor. _________________________________ Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
