Re: allowing for a completely cached umount(2) pathwalk

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> 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





[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux