Re: fanotify sb/mount watch inside userns (Was: [PATCH RFC] : fhandle: relax open_by_handle_at() permission checks)
Amir Goldstein <[email protected]> Fri, 18 Apr 2025 13:32:48 +0200
| Newsgroups | dev.linux.lists.containers,org.kernel.vger.linux-fsdevel |
|---|---|
| Message-ID | <CAOQ4uxgwfQNM=cRBJ0BJ-UtZ1R=v3uuFrOfLxWCr5c0WA_Nh3w@mail.gmail.com> |
On Wed, Oct 16, 2024 at 2:53=E2=80=AFPM Amir Goldstein <[email protected]>= wrote: > ... > > > > Christian, > > > > > > > > Follow up question: > > > > Now that open_by_handle_at(2) is supported from non-root userns, > > > > What about this old patch [1] to allow sb/mount watches from non-ro= ot userns? > > > > > > > > ... > > > > My question is whether this is useful, because there are still a few > > limitations. > > I will start with what is possible with this patch: > > 1. Watch an entire tmpfs filesystem that was mounted inside userns > > 2. Watch an entire overlayfs filesystem that was mounted [*] inside use= rns > > 3. Watch an entire mount [**] of any [***] filesystem that was > > idmapped mounted into userns > > > > Now the the fine prints: > > [*] Overlayfs sb/mount CAN be watched, but decoding file handle in > > events to path > > only works if overlayfs is mounted with mount option > > nfs_export=3Don, which conflicts > > with mount option metacopy=3Don, which is often used in containers > > (e.g. podman) > > [**] Watching a mount is only possible with the legacy set of fanotify = events > > (i.e. open,close,access,modify) so this is less useful for > > directory tree change tracking > > [***] Watching an idmapped mount has the same limitations as watching > > an sb/mount > > in the root userns, namely, filesystem needs to have a non zero > > fsid (so not FUSE) > > and filesystem needs to have a uniform fsid (so not btrfs > > subvolume), although > > with some stretch, I could make watching an idmapped mount of > > btrfs subvol work. > > > > No support for watching btrfs subvol and overlayfs with metacopy=3Don, > > reduces the attractiveness for containers, but perhaps there are still = use cases > > where watching an idmapped mount or userns private tmpfs are useful? > > > > To try out this patch inside your favorite container/userns, you can bu= ild > > fsnotifywait with a patch to support watching inside userns [2]. > > It's actually only the one lines O_DIRECTORY patch that is needed for t= he > > basic tmpfs userns mount case. > > > > Jan, > > > > If we do not get any buy-in from potential consumers now, do you think = that > > we should go through with the patch and advertise the new supported use= cases, > > so that users may come later on? > > Hi guys, The fine print section in the above "is it useful" question is quite comple= x. Maybe that explains why I got no response ;) I can now ask another flavor of the question: Is it useful to allow FAN_MARK_MNTNS watches from non-root userns? Just to make sure that I get it right, the unique mntid that is reported wi= th mount attach/detach events is not namespaced right? Anyway, this functionality has become a priority for me, so I will work on adapting the old patch [3] to mntns marks and post v2. Thanks, Amir. [1] https://github.com/amir73il/linux/commits/fanotify_userns/ [2] https://github.com/amir73il/inotify-tools/commits/fanotify_userns/ [3] https://lore.kernel.org/linux-fsdevel/20230416060722.1912831-1-amir73il= @gmail.com/