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

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

On Thu, Mar 18, 2021 at 06:48:11PM +0200, Amir Goldstein wrote:
> [...]
> 
> I understand the use case.
> 
> > I'd rather have something that allows me to mirror
> >
> > /home/jdoe
> >
> > recursively directly. But maybe I'm misunderstanding fanotify and it
> > can't really help us but I thought that subtree watches might.
> >
> 
> There are no subtree watches. They are still a holy grale for fanotify...
> There are filesystem and mnt watches and the latter support far fewer
> events (only events for operations that carry the path argument).
> 
> With filesystem watches, you can get events for all mkdirs and you can
> figure out the created path, but you'd have to do all the filtering in
> userspace.
> 
> What I am trying to create is "filtered" filesystem watches and the filter needs
> to be efficient enough so the watcher will not incur too big of a penalty
> on all the operations in the filesystem.
> 
> Thanks to your mnt_userns changes, implementing a filter to intercept
> (say) mkdir calles on a specific mnt_userns should be quite simple, but
> filtering by "path" (i.e. /home/jdoe/some/path) will still need to happen in
> userspace.
> 
> This narrows the problem to the nested container manager that will only
> need to filter events which happened via mounts under its control.
> 
> [...]
> 
> > > there shouldn't be a problem to setup userns filtered watches in order to
> > > be notified on all the events that happen via those idmapped mounts
> > > and filtering by "subtree" is not needed.
> > > I am clearly far from understanding the big picture.
> >
> > I think I need to refamiliarize myself with what "subtree" watches do.
> > Maybe I misunderstood what they do. I'll take a look.
> >
> 
> You will not find them :-)

Heh. :)

> 
> [...]
> 
> > > Currently, (upstream) only init_userns CAP_SYS_ADMIN can setup
> > > fanotify watches.
> > > In linux-next, unprivileged user can already setup inode watches
> > > (i.e. like inotify).
> >
> > Just to clarify: you mean "unprivileged" as in non-root users in
> > init_user_ns and therefore also users in non-init userns. That's what
> 
> Correct.
> 
> > inotify allows you. This would probably allows us to use fanotify
> > instead of the hand-rolled recursive notify watching we currently do and
> > that I linked to above.
> >
> 
> The code that sits in linux-next can give you pretty much a drop-in
> replacement of inotify and nothing more. See example code:
> https://github.com/amir73il/inotify-tools/commits/fanotify_name_fid

This is really great. Thank you for doing that work this will help quite
a lot of use-cases and make things way simpler. I created a TODO to port
our path-hotplug to this once this feature lands.

> 
> > > If you think that is useful and you want to play with this feature I can
> > > provide a WIP branch soon.
> >
> > I would like to first play with the support for unprivileged fanotify
> > but sure, it does sound useful!
> 
> Just so you have an idea what I am talking about, this is a very early
> POC branch:
> https://github.com/amir73il/linux/commits/fanotify_userns

Thanks!  I'll try to pull this and take a look next week. I hope that's
ok.

Christian