On Wed, Oct 16, 2024 at 2:53 PM Amir Goldstein <amir73il@xxxxxxxxx> 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-root 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 userns > > 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=on, which conflicts > > with mount option metacopy=on, 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=on, > > 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 build > > fsnotifywait with a patch to support watching inside userns [2]. > > It's actually only the one lines O_DIRECTORY patch that is needed for the > > 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 complex. 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 with 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@xxxxxxxxx/
