Re: robinhood, fanotify name info events and lustre changelog

["Quentin.BOUGET@cea.fr" <Quentin.BOUGET@cea.fr>]

> > > > > 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