From: Eric Paris <eparis@redhat.com>
To: linux-kernel@vger.kernel.org, malware-list@lists.printk.net
Cc: viro@ZenIV.linux.org.uk, alan@lxorguk.ukuu.org.uk,
arjan@infradead.org, greg@kroah.com, tytso@mit.edu
Subject: [PATCH -v2 13/16] fanotify: ability for userspace to delay responses
Date: Tue, 14 Oct 2008 16:52:38 -0400 [thread overview]
Message-ID: <20081014205238.1057.6024.stgit@paris.rdu.redhat.com> (raw)
In-Reply-To: <20081014205009.1057.12041.stgit@paris.rdu.redhat.com>
Userspace may know that it is behind, may know it is going to take a while
to get a good response, or have any number of other reasons to block an
access request. FAN_RESTTIMER will reset the timeout for an fanotify
access decision response.
Signed-off-by: Eric Paris <eparis@redhat.com>
---
fs/notify/access.c | 31 +++++++++++++++++++++++++++----
fs/notify/fanotify.h | 1 +
fs/notify/notification.c | 2 ++
include/linux/fanotify.h | 1 +
4 files changed, 31 insertions(+), 4 deletions(-)
diff --git a/fs/notify/access.c b/fs/notify/access.c
index 6a2606c..5b3b32e 100644
--- a/fs/notify/access.c
+++ b/fs/notify/access.c
@@ -55,6 +55,8 @@ int fanotify_add_event_to_access(struct fanotify_group *group, struct fanotify_e
int fanotify_get_response_from_access(struct fanotify_group *group, struct fanotify_event *event)
{
int ret;
+
+retry:
ret = wait_event_interruptible_timeout(group->access_waitq,
event->response,
msecs_to_jiffies(5000));
@@ -89,13 +91,25 @@ int fanotify_get_response_from_access(struct fanotify_group *group, struct fanot
}
/* userspace responded, convert to something usable */
+ spin_lock(&event->response_lock);
switch (event->response) {
case FAN_ALLOW:
- return 0;
+ ret = 0;
+ break;
case FAN_DENY:
+ ret = -EPERM;
+ break;
+ case FAN_RESETTIMER:
+ event->response = 0;
+ spin_unlock(&event->response_lock);
+ goto retry;
default:
- return -EPERM;
+ ret = -EPERM;
+ break;
}
+ spin_unlock(&event->response_lock);
+
+ return ret;
}
int fanotify_process_access_response(struct fanotify_group *group, unsigned long cookie, unsigned int response)
@@ -108,7 +122,7 @@ int fanotify_process_access_response(struct fanotify_group *group, unsigned long
* userspace can send a valid responce or we will clean it up after the
* timeout
*/
- if (response & ~(FAN_ALLOW | FAN_DENY))
+ if (response & ~(FAN_ALLOW | FAN_DENY | FAN_RESETTIMER))
return -EINVAL;
mutex_lock(&group->access_mutex);
@@ -117,6 +131,11 @@ int fanotify_process_access_response(struct fanotify_group *group, unsigned long
continue;
event = holder->event;
+
+ /* FAN_RESETTIMER should be left on the list for later.... */
+ if (response == FAN_RESETTIMER)
+ break;
+
spin_lock(&event->holder_spinlock);
holder->event = NULL;
/* as soon as we do this the event.holder might be reused */
@@ -132,9 +151,13 @@ int fanotify_process_access_response(struct fanotify_group *group, unsigned long
if (!event)
return -ENOENT;
+ spin_lock(&event->response_lock);
event->response = response;
+ spin_unlock(&event->response_lock);
wake_up(&group->access_waitq);
- fanotify_put_event(event);
+
+ if (response != FAN_RESETTIMER)
+ fanotify_put_event(event);
return 0;
}
diff --git a/fs/notify/fanotify.h b/fs/notify/fanotify.h
index e07703f..d65db61 100644
--- a/fs/notify/fanotify.h
+++ b/fs/notify/fanotify.h
@@ -48,6 +48,7 @@ struct fanotify_event {
atomic_t refcnt; /* how many groups still are using/need to send this event */
/* if waiting for a userspace access answer this is the cookie they will send back */
unsigned long cookie;
+ spinlock_t response_lock; /* protects response */
unsigned int response; /* userspace answer to question */
};
diff --git a/fs/notify/notification.c b/fs/notify/notification.c
index 89bb02c..dd0d2db 100644
--- a/fs/notify/notification.c
+++ b/fs/notify/notification.c
@@ -27,6 +27,7 @@
#include <linux/path.h>
#include <linux/sched.h>
#include <linux/slab.h>
+#include <linux/spinlock.h>
#include <linux/fanotify.h>
#include "fanotify.h"
@@ -169,6 +170,7 @@ struct fanotify_event *create_event(struct file *file, unsigned int mask)
event->holder.event = NULL;
INIT_LIST_HEAD(&event->holder.event_list);
atomic_set(&event->refcnt, 1);
+ spin_lock_init(&event->response_lock);
spin_lock_init(&event->holder_spinlock);
diff --git a/include/linux/fanotify.h b/include/linux/fanotify.h
index b5c9db9..a36bd6b 100644
--- a/include/linux/fanotify.h
+++ b/include/linux/fanotify.h
@@ -49,6 +49,7 @@
/* answers will need to be either allow or deny */
#define FAN_ALLOW 0x00000001
#define FAN_DENY 0x00000002
+#define FAN_RESETTIMER 0x00000004
#ifdef __KERNEL__
#include <linux/types.h>
next prev parent reply other threads:[~2008-10-14 20:57 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-14 20:51 [PATCH -v2 00/16] fanotify: novel all file access notification and permissions system Eric Paris
2008-10-14 20:51 ` [PATCH -v2 01/16] filesystem notification: create fs/notify to contain all fs notification Eric Paris
2008-10-14 20:51 ` [PATCH -v2 02/16] fsnotify: pass a file instead of an inode to open, read, and write Eric Paris
2008-10-14 20:51 ` [PATCH -v2 03/16] fanotify: fscking all notify, system wide file access notification Eric Paris
2008-10-14 20:51 ` [PATCH -v2 04/16] fsnotify: sys_execve and sys_uselib do not call into fsnotify Eric Paris
2008-10-14 20:51 ` [PATCH -v2 05/16] fanotify: make use of the new fsnotify_open_exec calls Eric Paris
2008-10-14 20:52 ` [PATCH -v2 06/16] fanotify: add a userspace interface for fanotify notifications Eric Paris
2008-10-14 20:52 ` [PATCH -v2 07/16] fanotify: fastpath to ignore certain in core inodes Eric Paris
2008-10-14 20:52 ` [PATCH -v2 08/16] fanotify: add a userspace interface for fastpaths Eric Paris
2008-10-14 20:52 ` [PATCH -v2 09/16] fanotify: add group priorities Eric Paris
2008-10-14 20:52 ` [PATCH -v2 10/16] fanotify: blocking and access granting Eric Paris
2008-10-14 20:52 ` [PATCH -v2 11/16] fanotify: give a special access permission check Eric Paris
2008-10-14 20:52 ` [PATCH -v2 12/16] fanotify: user interface for access decisions Eric Paris
2008-10-14 20:52 ` Eric Paris [this message]
2008-10-14 20:52 ` [PATCH -v2 14/16] fanotify: send pid with fanotify notification events Eric Paris
2008-10-14 20:52 ` [PATCH -v2 15/16] fanotify: send tgid with notification messages Eric Paris
2008-10-14 20:52 ` [PATCH -v2 16/16] fanotify: send file f_flags along with notifications 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=20081014205238.1057.6024.stgit@paris.rdu.redhat.com \
--to=eparis@redhat.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=arjan@infradead.org \
--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
all inboxes | Powered by JetHome®