linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andreas Gruenbacher <agruen@suse.de>
To: Tvrtko Ursulin <tvrtko.ursulin@sophos.com>
Cc: Eric Paris <eparis@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: [BUG][PATCH][2.6.36-rc3] fanotify: Do not ignore result of permission decisions
Date: Fri, 8 Oct 2010 15:00:40 +0200	[thread overview]
Message-ID: <201010081500.40494.agruen@suse.de> (raw)
In-Reply-To: <201009080924.04841.tvrtko.ursulin@sophos.com>

Tvrtko,

On Wednesday 08 September 2010 10:24:04 Tvrtko Ursulin wrote:
> 
> Improved version of the fix which does not include the check
> when permission events are not enabled in configuration and
> stops processing if no interesting events remain.
> 
> Current code ignores access replies to permission decisions so
> fix it in a way which will allow all listeners to still receive
> non permission events.

I agree with the patch (see comments below), but this explanation is close
to incomprehensible and not good as a commit message.

> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@sophos.com>
> ---
>  fs/notify/fsnotify.c             |   32 ++++++++++++++++++++++++--------
>  include/linux/fsnotify_backend.h |    4 ++++
>  2 files changed, 28 insertions(+), 8 deletions(-)
> 
> diff --git a/fs/notify/fsnotify.c b/fs/notify/fsnotify.c
> index 3680242..2350a53 100644
> --- a/fs/notify/fsnotify.c
> +++ b/fs/notify/fsnotify.c
> @@ -224,7 +224,7 @@ int fsnotify(struct inode *to_tell, __u32 mask, void *data, int data_is,
>         struct fsnotify_group *inode_group, *vfsmount_group;
>         struct fsnotify_event *event = NULL;
>         struct vfsmount *mnt;
> -       int idx, ret = 0;
> +       int idx, ret = 0, res;
>         /* global tests shouldn't care about events on child only the specific event */
>         __u32 test_mask = (mask & ~FS_EVENT_ON_CHILD);
> 
> @@ -275,20 +275,36 @@ int fsnotify(struct inode *to_tell, __u32 mask, void *data, int data_is,
> 
>                 if (inode_group > vfsmount_group) {
>                         /* handle inode */
> -                       send_to_group(to_tell, NULL, inode_mark, NULL, mask, data,
> -                                     data_is, cookie, file_name, &event);
> +                       res = send_to_group(to_tell, NULL, inode_mark, NULL, mask, data,
> +                                           data_is, cookie, file_name, &event);
>                         /* we didn't use the vfsmount_mark */
>                         vfsmount_group = NULL;
>                 } else if (vfsmount_group > inode_group) {
> -                       send_to_group(to_tell, mnt, NULL, vfsmount_mark, mask, data,
> -                                     data_is, cookie, file_name, &event);
> +                       res = send_to_group(to_tell, mnt, NULL, vfsmount_mark, mask, data,
> +                                           data_is, cookie, file_name, &event);
>                         inode_group = NULL;
>                 } else {
> -                       send_to_group(to_tell, mnt, inode_mark, vfsmount_mark,
> -                                     mask, data, data_is, cookie, file_name,
> -                                     &event);
> +                       res = send_to_group(to_tell, mnt, inode_mark, vfsmount_mark,
> +                                           mask, data, data_is, cookie, file_name,
> +                                           &event);
>                 }
> 
> +#ifdef CONFIG_FANOTIFY_ACCESS_PERMISSIONS
> +               /* If a listener denied on a permission event we will remember the reason
> +                  and run the rest with a non-permission mask only. This allows other
> +                  listeners to receive non-permission notifications but we do not care
> +                  about further permission checks and want to deny this event. */
> +               if (unlikely((res == -EPERM) && (mask & FS_ALL_PERM_EVENTS))) {

We should probably stop processing here whenever res != 0, for any mask. (The
fanotify and inotify handle_event callbacks can return -ENOMEM right now, but
this doesn't seem very useful and should probably be fixed: fsnotify has no
way of doing anything about -ENOMEM.

> +                       mask &= ~FS_ALL_PERM_EVENTS;
> +                       ret = res;
> +                       /* Stop processing if no interesting events remains. */
> +                       if (!(mask & (ALL_FSNOTIFY_EVENTS & ~FS_EVENT_ON_CHILD)))
> +                               break;
> +               }
> +#else
> +               (void)res;
> +#endif
> +
>                 if (inode_group)
>                         inode_node = srcu_dereference(inode_node->next,
>                                                       &fsnotify_mark_srcu);
> diff --git a/include/linux/fsnotify_backend.h b/include/linux/fsnotify_backend.h
> index e40190d..c8aea03 100644
> --- a/include/linux/fsnotify_backend.h
> +++ b/include/linux/fsnotify_backend.h
> @@ -64,6 +64,10 @@
> 
>  #define FS_MOVE                        (FS_MOVED_FROM | FS_MOVED_TO)
> 
> +/* All events which require a permission response from userspace */
> +#define FS_ALL_PERM_EVENTS (FS_OPEN_PERM |\
> +                           FS_ACCESS_PERM)

When dealing with the result of ->handle_event as I propose, this definition
isn't needed.

Thanks,
Andreas

  reply	other threads:[~2010-10-08 13:01 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-07 15:08 [BUG][PATCH][2.6.36-rc3] fanotify: Do not ignore result of permission decisions Tvrtko Ursulin
2010-09-08  8:24 ` Tvrtko Ursulin
2010-10-08 13:00   ` Andreas Gruenbacher [this message]
2010-10-08 16:11     ` Tvrtko Ursulin
2010-10-08 16:51       ` Eric Paris
2010-10-18 11:05         ` Tvrtko Ursulin
2010-10-08 21:05       ` Andreas Gruenbacher

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=201010081500.40494.agruen@suse.de \
    --to=agruen@suse.de \
    --cc=eparis@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tvrtko.ursulin@sophos.com \
    /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;
as well as URLs for NNTP newsgroup(s).