linux-kernel - Re: [PATCH 10/20] fanotify: allow userspace to override max queue depth

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <201011011734.56269.tvrtko.ursulin@sophos.com>
Date:	Mon, 1 Nov 2010 17:34:55 +0000
From:	Tvrtko Ursulin <tvrtko.ursulin@...hos.com>
To:	Eric Paris <eparis@...hat.com>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
	"agruen@...e.de" <agruen@...e.de>
Subject: Re: [PATCH 10/20] fanotify: allow userspace to override max queue depth

On Monday 01 Nov 2010 17:23:51 Eric Paris wrote:
> On Mon, 2010-11-01 at 17:09 +0000, Tvrtko Ursulin wrote:
> > On Thursday 28 Oct 2010 22:32:32 Eric Paris wrote:
> > > fanotify has a defualt max queue depth.  This patch allows processes
> > > which explicitly request it to have an 'unlimited' queue depth.  These
> > > processes need to be very careful to make sure they cannot fall far
> > > enough behind that they OOM the box.  Thus this flag is gated on
> > > CAP_SYS_ADMIN.
> > >
> > > Signed-off-by: Eric Paris <eparis@...hat.com>
> > > ---
> > >
> > >  fs/notify/fanotify/fanotify_user.c |    9 ++++++++-
> > >  include/linux/fanotify.h           |    5 +++--
> > >  2 files changed, 11 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/fs/notify/fanotify/fanotify_user.c
> > > b/fs/notify/fanotify/fanotify_user.c index 04f2fe4..43d66d9 100644
> > > --- a/fs/notify/fanotify/fanotify_user.c
> > > +++ b/fs/notify/fanotify/fanotify_user.c
> > > @@ -691,7 +691,14 @@ SYSCALL_DEFINE2(fanotify_init, unsigned int,
> > > flags, unsigned int, event_f_flags) goto out_put_group;
> > >
> > >       }
> > >
> > > -     group->max_events = FANOTIFY_DEFAULT_MAX_EVENTS;
> > > +     if (flags & FAN_UNLIMITED_QUEUE) {
> > > +             fd = -EPERM;
> > > +             if (!capable(CAP_SYS_ADMIN))
> > > +                     goto out_put_group;
> >
> > Either this capable call is not needed or the one at the top of the
> > syscall needs to go if you intended to allow non-privileged access.
>
> I realize they are redundant.  But it is starting down the path of
> unpriv'd users.  I figure I already have to go back and audit everything
> we do looking for places we shouldn't allow unpriv users, so no need to
> add new ones without explicitly checking.

True, next patch mentions this higher motive, sorry for the noise.

Tvrtko

Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon, OX14 3YP, United Kingdom.
Company Reg No 2096520. VAT Reg No GB 348 3873 20.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/