> > > > With fanotify FAN_CREATE event, for example, the parent fid + name > > > > information should be used by the rbh adapter code to call > > > > name_to_handle_at(2) and get the created object's file handle. > > > > > > > > The reason we made this API choice is because fanotify events should > > > > not be perceived as a sequence of changes that can be followed to > > > > describe the current state of the filesystem. > > > > fanotify events should be perceived as a "poll" on the namespace. > > > > Whenever notified of a change, application should read the current state > > > > for the filesystem. fanotify events provide "just enough" information, so > > > > reading the current state of the filesystem is not too expensive. > > I am a little worried about objects that would move around constantly and thus > "evade" name_to_handle_at(). A bad actor could try to hide a setuid binary this > way... Of course they could also just copy/delete the file repeatedly and in > this case having the fid becomes useless, but it seems harder to do, and it is > likely it would take more time than a simple rename. > I am not following. This threat model sounds bogus, but I am not a security expert, and fanotify async events shouldn't have anything to do with security. If you can write a concrete use case and explain how your application wants to handle it and why it cannot without the missing object fid information I get give a serious answer. > > > > When fanotify event FAN_MODIFY reports a change of file size, > > > > along with parent fid + name, that do not match the parent/name robinhood > > > > knows about (i.e. because the event is received out of order with rename), > > > > you may use that information to create rbh_fsevent_ns_xattr event to > > > > update the path or you may wait for the FAN_MOVE_SELF event that > > > > should arrive later. > > > > Up to you. > > This is making me think: if I receive such a FAN_MODIFY event, and an object > is moved at parent_fid + name before I query the FS, how can I know which file > the event was originally meant for? > FAN_MODIFY/FAN_ACCESS/FAN_ATTRIB events do have the object_fid in addition to parent_fid + name. FAN_CREATE/FAN_DELETE/FAN_MOVE do NOT have the object_fid, FAN_DELETE_SELF/FAN_MOVE_SELF do have the object_fid FAN_DELETE_SELF does NOT have parent_fid + name FAN_MOVE_SELF does have parent_fid + name (new parent/name) Is there anything missing in your opnion for robinhood to be able to perform any of its missions? Thanks, Amir.
