From: Marko Rauhamaa <marko.rauhamaa@f-secure.com>
To: Jan Kara <jack@suse.cz>
Cc: "Filip Štědronský" <r.lkml@regnarg.cz>,
"Amir Goldstein" <amir73il@gmail.com>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
"Alexander Viro" <viro@zeniv.linux.org.uk>
Subject: Re: [RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes
Date: Wed, 15 Mar 2017 16:18:03 +0200 [thread overview]
Message-ID: <87k27q4o9w.fsf@drapion.f-secure.com> (raw)
In-Reply-To: <20170315133952.GH12989@quack2.suse.cz> (Jan Kara's message of "Wed, 15 Mar 2017 14:39:52 +0100")
Jan Kara <jack@suse.cz>:
> On Wed 15-03-17 10:19:52, Marko Rauhamaa wrote:
>> As for "who (user/process/...) did what", the fanotify API is flawed
>> in that we don't have a CLOSE_WRITE_PERM event. The hit-and-run
>> process is long gone by the time we receive the event. That's more of
>> a rule than an exception.
>
> Adding CLOSE_WRITE_PERM would not be that difficult I assume. What do you
> need it for?
Mainly to hold the process hostage until I have verified the content
change. If I disqualify the content change, I will need to report on the
process. CLOSE_WRITE only gives me a pid that is often stale as it
doesn't block the process.
(Another possibility would be to keep the process around as a zombie as
long as the CLOSE_WRITE event's file descriptor is open. That sounds
more complicated and questionable, though.)
Marko
--
+358 44 990 4795
Skype: marko.rauhamaa_f-secure
next prev parent reply other threads:[~2017-03-15 14:19 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-13 23:02 [RFC 1/2] fanotify: new event FAN_MODIFY_DIR Filip Štědronský
2017-03-13 23:03 ` [RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes Filip Štědronský
2017-03-14 11:18 ` Amir Goldstein
2017-03-14 14:58 ` Filip Štědronský
2017-03-14 15:35 ` Amir Goldstein
2017-03-15 8:19 ` Marko Rauhamaa
2017-03-15 13:39 ` Jan Kara
2017-03-15 14:18 ` Marko Rauhamaa [this message]
2017-03-15 14:44 ` Amir Goldstein
2017-03-19 10:19 ` Jan Kara
2017-03-19 10:37 ` Filip Štědronský
2017-03-19 18:04 ` Jan Kara
2017-03-20 11:40 ` Amir Goldstein
2017-03-20 11:52 ` Filip Štědronský
2017-03-21 15:38 ` J. Bruce Fields
2017-03-21 16:41 ` Jan Kara
2017-03-21 17:45 ` J. Bruce Fields
2017-03-13 23:16 ` [RFC 1/2] fanotify: new event FAN_MODIFY_DIR Filip Štědronský
2017-03-14 10:40 ` Amir Goldstein
2017-03-14 13:46 ` Filip Štědronský
2017-03-14 15:07 ` Amir Goldstein
2017-03-20 12:10 ` Amir Goldstein
2017-03-14 10:11 ` Amir Goldstein
2017-03-14 12:41 ` Filip Štědronský
2017-03-14 13:55 ` Amir Goldstein
2017-03-14 14:48 ` Filip Štědronský
2017-03-14 22:30 ` Amir Goldstein
2017-03-15 14:05 ` Jan Kara
2017-03-15 14:34 ` Amir Goldstein
2017-03-16 10:38 ` Jan Kara
2017-03-15 4:52 ` Michael Kerrisk
2017-03-15 4:52 ` Michael Kerrisk
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=87k27q4o9w.fsf@drapion.f-secure.com \
--to=marko.rauhamaa@f-secure.com \
--cc=amir73il@gmail.com \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=r.lkml@regnarg.cz \
--cc=viro@zeniv.linux.org.uk \
/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.