Re: robinhood, fanotify name info events and lustre changelog

quoted

quoted

quoted

quoted

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.

quoted

quoted

quoted

quoted

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