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

From: Amir Goldstein <amir73il@gmail.com>
To: Christian Brauner <christian.brauner@ubuntu.com>
Cc: Jan Kara <jack@suse.cz>,
	Matthew Bobrowski <mbobrowski@mbobrowski.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Linux API <linux-api@vger.kernel.org>
Subject: Re: [PATCH v2 0/2] unprivileged fanotify listener
Date: Thu, 18 Mar 2021 18:48:11 +0200	[thread overview]
Message-ID: <CAOQ4uxiRHwmxTKsLteH_sBW_dSPshVE8SohJYEmpszxaAwjEyg@mail.gmail.com> (raw)
In-Reply-To: <20210318143140.jxycfn3fpqntq34z@wittgenstein>

[...]

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 :-)

[...]

> > 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

> > 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

It will not be very useful to you yet I think.
Userns admin can watch all events on a tmpfs/fuse mounted
inside its userns.
Userns admin can watch open/read/write/close events on an
idmapped mount mapped to its userns.
But I think the more useful feature would be to watch all events on
an idmapped mount mapped to its userns.

Thanks,
Amir.