On Tue, Dec 10, 2024 at 05:11:30PM +0100, Miklos Szeredi wrote: > On Fri, 6 Dec 2024 at 19:29, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > > Because with fanotify the event mask is used both as a filter for subscribe > > and as a filter to the reported event->mask, so with your current patch > > a user watching only FAN_MNT_DETACH, will get a FAN_MNT_DETACH > > event on mount move. Is that the intention? > > I imagine there's a case for watching a single mount and seeing if it > goes away. In that case it's irrelevant whether the mount got moved Sooner or later we'll likely need something like this but I think the mount namespace stuff is needed a lot more. > away or it was destroyed. > > > Is there even a use case for watching only attach or only detach? > > I'm not sure, there could well be. I'm pretty certain that there is. One might care just about incoming mounts into a system service due to mount propagation to detect when a new volume is added but not care about it going away. I think lumping both events together isn't a great idea. > > > Are we ever likely to add more mount events besides attach/detach? > > Yes, modification (i.e. flag/propagation/etc changes). And that one > could really make sense on a per-mount basis instead of per-ns. Yes, that's what I envision as well. Though we really have to be careful to make sure that we don't end up shooting us in the foot by sprinkling notifications everywhere into the code.
