Re: [PATCH v2 0/2] unprivileged fanotify listener

[Christian Brauner <christian.brauner@ubuntu.com>]

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