> > > > > 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. A few weeks ago, attacks on supercomputers were reported: https://www.bbc.com/news/technology-52709660. I am not privy to the mitigations/detection mechanisms put in place, but it is my understanding that one thing people have been looking for are setuid/setgid binaries. If robinhood can be trusted to "see" (and stat) every file created/modified on a filesystem, then it can be used for a rapid filesystem-wide scan. EDIT: That's my bad, I should have tried fanotify first. Now that I have, I can see that FAN_CREATE is not the only event that is emitted when a file is created and so, even if robinhood does not see the "right" file at parent_fid + name, it will still see the created file's fid later on as it receives the associated FAN_OPEN event. Sorry. > > > > > 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? No, I don't think so anymore. Thanks, Quentin
