From: Christoph Hellwig <hch@infradead.org>
To: Eric Paris <eparis@redhat.com>
Cc: linux-kernel@vger.kernel.org, malware-list@lists.printk.net,
viro@zeniv.linux.org.uk, alan@lxorguk.ukuu.org.uk,
arjan@infradead.org, greg@kroah.com, tytso@mit.edu,
akpm@linux-foundation.org
Subject: Re: [PATCH =-v3 11/21] fanotify: give a special access permission check
Date: Wed, 12 Nov 2008 11:53:25 -0500 [thread overview]
Message-ID: <20081112165325.GC19669@infradead.org> (raw)
In-Reply-To: <20081112161124.25434.86250.stgit@paris.rdu.redhat.com>
On Wed, Nov 12, 2008 at 11:11:24AM -0500, Eric Paris wrote:
> fsnotify_open_exec(file);
> + error = fanotify(file, FAN_ACCESS_EXEC_PERM);
> + if (error) {
> + fput(file);
> + goto out;
> + }
Adding your own fanotify calls next to the fsnotify calls completely
defeats th purpose of these. Please make sure we have one set of hooks.
And given that we now have three notification schemes I think it's
getting time that you also unifify the actuall backends (buffering, etc)
instead of faning out at the fsnotify layer and just leave dnotify and
inotify as tiny userspace interface layers.
next prev parent reply other threads:[~2008-11-12 16:53 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-12 16:10 [PATCH =-v3 00/21] fanotify: novel file access notification and permission system Eric Paris
2008-11-12 16:10 ` [PATCH =-v3 01/21] filesystem notification: create fs/notify to contain all fs notification Eric Paris
2008-11-12 16:10 ` [PATCH =-v3 02/21] fsnotify: pass a file instead of an inode to open, read, and write Eric Paris
2008-11-12 16:10 ` [PATCH =-v3 03/21] fanotify: fscking all notify, system wide file access notification Eric Paris
2008-11-12 16:10 ` [PATCH =-v3 04/21] fsnotify: sys_execve and sys_uselib do not call into fsnotify Eric Paris
2008-11-12 16:49 ` Christoph Hellwig
2008-11-12 21:15 ` Eric Paris
2008-11-12 16:10 ` [PATCH =-v3 05/21] fanotify: make use of the new fsnotify_open_exec calls Eric Paris
2008-11-12 16:10 ` [PATCH =-v3 06/21] fanotify: add a userspace interface for fanotify notifications Eric Paris
2008-11-12 16:11 ` [PATCH =-v3 07/21] fanotify: fastpath to ignore certain in core inodes Eric Paris
2008-11-12 16:50 ` Christoph Hellwig
2008-11-12 16:56 ` Alan Cox
2008-11-12 16:58 ` Christoph Hellwig
2008-11-12 20:52 ` Eric Paris
2009-12-08 15:22 ` John Ogness
2008-11-12 22:38 ` Peter Zijlstra
2008-11-12 16:11 ` [PATCH =-v3 08/21] fanotify: add a userspace interface for fastpaths Eric Paris
2008-11-12 16:11 ` [PATCH =-v3 09/21] fanotify: add group priorities Eric Paris
2008-11-12 16:11 ` [PATCH =-v3 10/21] fanotify: blocking and access granting Eric Paris
2008-11-12 16:11 ` [PATCH =-v3 11/21] fanotify: give a special access permission check Eric Paris
2008-11-12 16:53 ` Christoph Hellwig [this message]
2008-11-12 21:23 ` Eric Paris
2008-11-12 16:11 ` [PATCH =-v3 12/21] fanotify: user interface for access decisions Eric Paris
2008-11-12 16:11 ` [PATCH =-v3 13/21] fanotify: ability for userspace to delay responses Eric Paris
2008-11-12 16:11 ` [PATCH =-v3 14/21] fanotify: send pid with fanotify notification events Eric Paris
2008-11-12 16:11 ` [PATCH =-v3 15/21] fanotify: send tgid with notification messages Eric Paris
2008-11-12 16:11 ` [PATCH =-v3 16/21] fanotify: send file f_flags along with notifications Eric Paris
2008-11-12 16:11 ` [PATCH =-v3 17/21] fanotify: add option to clear all fastpaths Eric Paris
2008-11-12 16:12 ` [PATCH =-v3 18/21] fanotify: all userspace to set timeouts Eric Paris
2008-11-12 16:56 ` Christoph Hellwig
2008-11-12 21:14 ` Eric Paris
2008-11-12 16:12 ` [PATCH =-v3 19/21] fanotify: evict misbehaving clients Eric Paris
2008-11-12 16:12 ` [PATCH =-v3 20/21] fanotify: allow fastpath entries to survive inode modification Eric Paris
2008-11-12 16:12 ` [PATCH =-v3 21/21] fanotify: add Documentation Eric Paris
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=20081112165325.GC19669@infradead.org \
--to=hch@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=arjan@infradead.org \
--cc=eparis@redhat.com \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=malware-list@lists.printk.net \
--cc=tytso@mit.edu \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox