On Sat, Mar 20, 2021 at 2:57 PM Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > > > > 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. FYI, fixed the CI build errors on fanotify_name_fid branch. > > > > 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. > > > > > > > > > > > > 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 :) > > 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). One thing I am struggling with is the language to describe user ns and idmapped mounts related logic. I have a feeling that I am getting the vocabulary all wrong. See my commit message text below. Editorial corrections would be appreciated. Thanks, Amir. --- fanotify: support sb mark filtered by idmapped mount For a group created inside userns, adding a mount mark is allowed if the mount is idmapped inside the group's userns and adding a filesystem mark is allowed if the filesystem was mounted inside the group's userns. Allow also adding a filesystem mark on a filesystem that is mounted in the group's userns via an idmapped mount. In that case, the mark is created with an internal flag, which indicates that events should be sent to the group only if they happened via an idmapped mount inside the group's userns. Signed-off-by: Amir Goldstein <amir73il@xxxxxxxxx>
