On Tue, Apr 8, 2025 at 8:55 PM Ibrahim Jirdeh <ibrahimjirdeh@xxxxxxxx> wrote: > > > 1. Start a new server instance > > 2. Set default response in case of new instance crash > > 3. Hand over a ref of the existing group fd to the new instance if the > > old instance is running > > 4. Start handling events in new instance (*) > > 5. Stop handling new events in old instance, but complete pending events > > 6. Shutdown old instance > > I think this should work for our case, we will only need to reconstruct > the group/interested mask in case of crash. I can help add the feature for > setting different default responses. > Please go ahead. We did not yet get any feedback from Jan on this idea, but ain't nothing like a patch to solicit feedback. > > Doing this for the mount level would be possible, but TBH, it does not look > > like the right object to be setting the moderation on, because even if we did > > set a default mask on a mount, it would have been easy to escape it by > > creating a bind mount, cloning a new mount namespace, etc. > > > > What is the reason that you are marking the mount? > > Is it so that you could have another "unmoderated" mount to > > populate the file conten? > > In that case you can opt-in for permission events on sb > > and opt-out from permission events on the "unmoderated" mount > > and you can also populate the file content with the FMODE_NONOTIFY > > fd provided in the permission event. > > Yes, essentially we surface and monitor read-only bind mounts of specific > directories. The current setup opts-in for events per mount (via FAN_MARK_MOUNT), > and initial access populates file contents. If theres a way to do this with > sb marks we can switch to that, it would simplify things. I saw theres some > discussion of similar use-cases in this thread on sb views: > https://lore.kernel.org/linux-fsdevel/20201109180016.80059-1-amir73il@xxxxxxxxx/ > This didn't get anywhere. But what you can do is mark the sb and opt-out of the main sb mount: fanotify_mark(fd, FAN_MARK_ADD | FAN_MARK_FILESYSTEM, FAN_OPEN_PERM, AT_FDCWD, "/data"); fanotify_mark(fd, FAN_MARK_ADD | FAN_MARK_MOUNT | FAN_MARK_IGNORE, FAN_OPEN_PERM, AT_FDCWD, "/data"); Then you will not get open perm events under /data, but if you do $ mount -o bind /data/hsm /data/hsm Now /data/hsm is a different mount and this mount does not have an opt-out for open perm, so you will get the events under /data/hsm. This should work for this very simple mount hierarchy, but every time that this mount namespace is cloned or the /data mount is propagated to another place in the mount namespace, it will be propaged without the opt-out. So this is a very poor man's subtree watch setup. > > I might have had some patches similar to this floating around. > > If you are interested in this feature, I could write and test a proper patch. > > That would be appreciated if its not too much trouble, the approach outlined > in sketch should be enough for our use-case (pending the sb vs mount monitoring > point you've raised). > Well, the only problem is when I can get to it, which does not appear to be anytime soon. If this is an urgent issue for you I could give you more pointers to try and do it yourself. There is one design decision that we would need to make before getting to the implementation. Assuming that this API is acceptable: fanotify_mark(fd, FAN_MARK_ADD | FAN_MARK_FILESYSTEM | FAN_MARK_DEFAULT, ... What happens when fd is closed? Can the sbinfo->default_mask out live the group fd? I think that closing this group should remove the default mask and then the default mask is at least visible at fdinfo of this fd. Otherwise, we would need another way to expose to userspace the sb default mask. Of course your service can put this fd with the default mask in the fd store so it will survive a service crash. Then we need to think about how we express the default mask in fsnotify_mark. I think we can express it with a flag like the flag FSNOTIFY_MARK_FLAG_HAS_IGNORE_FLAGS and enforce that if a mark HAS_DEFAULT_MASK, then the user can only set FAN_MARK_DEFAULT, the same way that FAN_MARK_IGNORE is sticky. IOW, you cannot mix FAN_MARK_DEFAULT and other type of masks (normal and ignore) on the sb mark on the same group. That's as far as hand waving goes. If you want more details please ask. Thanks, Amir.
