All of lore.kernel.org
 help / color / mirror / Atom feed
From: Amir Goldstein <amir73il@gmail.com>
To: "Quentin.BOUGET@cea.fr" <Quentin.BOUGET@cea.fr>
Cc: Dominique Martinet <asmadeus@codewreck.org>,
	Jan Kara <jack@suse.cz>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"linux-api@vger.kernel.org" <linux-api@vger.kernel.org>,
	"robinhood-devel@lists.sf.net" <robinhood-devel@lists.sf.net>
Subject: Re: robinhood, fanotify name info events and lustre changelog
Date: Mon, 1 Jun 2020 23:20:05 +0300	[thread overview]
Message-ID: <CAOQ4uxjdPVWnK8807XzPv_DLa6zqyeMzX6Ezm1r_680DziXxYw@mail.gmail.com> (raw)
In-Reply-To: <1591040775412.28640@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.

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

  reply	other threads:[~2020-06-01 20:20 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-27 17:21 [GIT PULL] Fanotify revert for 5.7-rc8 Jan Kara
2020-05-27 18:10 ` pr-tracker-bot
     [not found] ` <20200527173937.GA17769@nautica>
     [not found]   ` <CAOQ4uxjQXwTo1Ug4jY1X+eBdLj80rEfJ0X3zKRi+L8L_uYSrgQ@mail.gmail.com>
2020-05-28 12:56     ` robinhood, fanotify name info events and lustre changelog Dominique Martinet
2020-05-29 18:41       ` Quentin.BOUGET
2020-05-30 13:07         ` Amir Goldstein
2020-05-30 13:39           ` Dominique Martinet
2020-05-30 20:37             ` Amir Goldstein
2020-06-01 19:46               ` Quentin.BOUGET
2020-06-01 20:20                 ` Amir Goldstein [this message]
2020-06-02  1:30                   ` Quentin.BOUGET

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAOQ4uxjdPVWnK8807XzPv_DLa6zqyeMzX6Ezm1r_680DziXxYw@mail.gmail.com \
    --to=amir73il@gmail.com \
    --cc=Quentin.BOUGET@cea.fr \
    --cc=asmadeus@codewreck.org \
    --cc=jack@suse.cz \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=robinhood-devel@lists.sf.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.