On Fri, Mar 19, 2021 at 3:40 PM Christian Brauner
[off-list ref] wrote:

On Thu, Mar 18, 2021 at 06:48:11PM +0200, Amir Goldstein wrote:

quoted

[...]

I understand the use case.

quoted

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.

[...]

quoted

quoted

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

quoted

[...]

quoted

quoted

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.

quoted

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.

FWIW, I just tried to build this branch on Ubuntu 20.04.2 with LTS kernel
and there were some build issues, so rebased my branch on upstream
inotify-tools to fix those build issues.

I was not aware that the inotify-tools project is alive, I never intended
to upstream this demo code and never created a github pull request
but rebasing on upstream brought in some CI scripts, when I pushed the
branch to my github it triggered some tests that reported build failures on
Ubuntu 16.04 and 18.04.

Anyway, there is a pre-rebase branch 'fanotify_name' and the post rebase
branch 'fanotify_name_fid'. You can try whichever works for you.

You can look at the test script src/test_demo.sh for usage example.
Or just cd into a writable directory and run the script to see the demo.
The demo determines whether to use a recursive watch or "global"
watch by the uid of the user.

quoted

quoted

quoted

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.

Fine. I'm curious to know what it does.
Did not get to test it with userns yet :)

Thanks,
Amir.