[...] 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.
