On Wed, Mar 24, 2021 at 03:57:12PM +0200, Amir Goldstein wrote: > > > Now tested FAN_MARK_FILESYSTEM watch on tmpfs mounted > > > inside userns and works fine, with two wrinkles I needed to iron: > > > > > > 1. FAN_REPORT_FID not supported on tmpfs because tmpfs has > > > zero f_fsid (easy to fix) > > > 2. open_by_handle_at() is not userns aware (can relax for > > > FS_USERNS_MOUNT fs) > > > > > > Pushed these two fixes to branch fanotify_userns. > > > > Pushed another fix to mnt refcount bug in WIP and another commit to > > add the last piece that could make fanotify usable for systemd-homed > > setup - a filesystem watch filtered by mnt_userns (not tested yet). > > > > Now I used mount-idmapped (from xfstest) to test that last piece. > Found a minor bug and pushed a fix. > > It is working as expected, that is filtering only the events generated via > the idmapped mount. However, because the listener I tested is capable in > the mapped userns and not in the sb userns, the listener cannot > open_ny_handle_at(), so the result is not as useful as one might hope. This is another dumb question probably but in general, are you saying that someone watching a mount or directory and does _not_ want file descriptors from fanotify to be returned has no other way of getting to the path they want to open other than by using open_by_handle_at()? > > I guess we will also need to make open_by_handle_at() idmapped aware > and use a variant of vfs_dentry_acceptable() that validates that the opened > path is legitimately accessible via the idmapped mount. So as a first step, I think there's a legitimate case to be made for open_by_handle_at() to be made useable inside user namespaces. That's a change worth to be made independent of fanotify. For example, nowadays cgroups have a 64 bit identifier that can be used with open_by_handle_at to map a cgrp id to a path and back: https://lkml.org/lkml/2020/12/2/1126 Right now this can't be used in user namespaces because of this restriction but it is genuinely useful to have this feature available since cgroups are FS_USERNS_MOUNT and that identifier <-> path mapping is very convenient. Without looking at the code I'm not super sure how name_to_handle_at() and open_by_handle_at() behave in the face of mount namespaces so that would need looking into to. But it would be a genuinely useful change, I think. > > I think I will leave this complexity to you should you think the userns filtered > watch is something worth the effort. Fair enough! Thanks! Christian
