All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Luis R. Rodriguez" <mcgrof@kernel.org>
To: Waiman Long <longman@redhat.com>
Cc: "Luis R. Rodriguez" <mcgrof@kernel.org>,
	Kees Cook <keescook@chromium.org>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Matthew Wilcox <willy@infradead.org>
Subject: Re: [PATCH v4 2/6] proc/sysctl: Check for invalid flags bits
Date: Mon, 12 Mar 2018 20:59:20 +0000	[thread overview]
Message-ID: <20180312205920.GD4449@wotan.suse.de> (raw)
In-Reply-To: <2621ea58-174f-bfe9-8c34-12501bb775fa@redhat.com>

On Mon, Mar 12, 2018 at 04:54:51PM -0400, Waiman Long wrote:
> On 03/12/2018 04:46 PM, Luis R. Rodriguez wrote:
> > On Mon, Mar 12, 2018 at 04:15:40PM -0400, Waiman Long wrote:
> >> Checking code is added to check for invalid flags in the ctl_table
> >> and return error if an unknown flag is used.
> > This should be merged with the first patch otherwise there are atomic
> > points in time on the commit log history where invalid values are allowed
> > and that makes no sense.
> >
> > This can probably be expanded to verify semantics further. Details
> > below.
> >> Signed-off-by: Waiman Long <longman@redhat.com>
> >> ---
> >>  fs/proc/proc_sysctl.c | 12 ++++++++++++
> >>  1 file changed, 12 insertions(+)
> >>
> >> diff --git a/fs/proc/proc_sysctl.c b/fs/proc/proc_sysctl.c
> >> index 493c975..67c0c82 100644
> >> --- a/fs/proc/proc_sysctl.c
> >> +++ b/fs/proc/proc_sysctl.c
> >> @@ -1092,6 +1092,16 @@ static int sysctl_check_table_array(const char *path, struct ctl_table *table)
> >>  	return err;
> >>  }
> >>  
> >> +static int sysctl_check_flags(const char *path, struct ctl_table *table)
> >> +{
> >> +	int err = 0;
> >> +
> >> +	if (table->flags & ~CTL_TABLE_FLAGS_ALL)
> >> +		err = sysctl_err(path, table, "invalid flags");
> > What if a range for the upper limit is set but not the lower limit and
> > the user goes over the lower limit?
> >
> > How about the inverse?
> >
> > Do we need both ranges set?
> >
> >   Luis
> 
> This check is just to make sure that no invalid flag bit is set. Range
> clamping is just one of flag bits, though this is the only one currently
> supported. In fact, it is allowed that the minimum or maximum can be
> left unspecified. In this case, no minimum or maximum checking will be
> done. So I don't see anything related to range checking should be put here.

What if minimum is greater than maximum?

  Luis

  reply	other threads:[~2018-03-12 20:59 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-12 20:15 [PATCH v4 0/6] ipc: Clamp *mni to the real IPCMNI limit Waiman Long
2018-03-12 20:15 ` [PATCH v4 1/6] sysctl: Add flags to support min/max range clamping Waiman Long
2018-03-12 20:44   ` Luis R. Rodriguez
2018-03-12 20:48     ` Waiman Long
2018-03-13 17:46   ` Eric W. Biederman
2018-03-13 18:49     ` Waiman Long
2018-03-12 20:15 ` [PATCH v4 2/6] proc/sysctl: Check for invalid flags bits Waiman Long
2018-03-12 20:46   ` Luis R. Rodriguez
2018-03-12 20:54     ` Waiman Long
2018-03-12 20:59       ` Luis R. Rodriguez [this message]
2018-03-12 21:02         ` Waiman Long
2018-03-12 20:52   ` Andrew Morton
2018-03-12 22:12     ` Waiman Long
2018-03-12 22:42       ` Andrew Morton
2018-03-12 20:15 ` [PATCH v4 3/6] sysctl: Warn when a clamped sysctl parameter is set out of range Waiman Long
2018-03-12 20:50   ` Luis R. Rodriguez
2018-03-12 21:07     ` Waiman Long
2018-03-12 21:00   ` Andrew Morton
2018-03-12 21:04     ` Waiman Long
2018-03-12 20:15 ` [PATCH v4 4/6] ipc: Clamp msgmni and shmmni to the real IPCMNI limit Waiman Long
2018-03-13 18:17   ` Eric W. Biederman
2018-03-13 18:39     ` Waiman Long
2018-03-13 20:29       ` Eric W. Biederman
2018-03-13 21:06         ` Waiman Long
     [not found]           ` <935a7c50-50cc-2dc0-33bb-92c000d039bc-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2018-03-15  0:49             ` [RFC][PATCH] ipc: Remove IPCMNI Eric W. Biederman
2018-03-15  0:49               ` Eric W. Biederman
     [not found]               ` <87woyego2u.fsf_-_-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2018-03-15 17:02                 ` Waiman Long
2018-03-15 19:45                 ` Matthew Wilcox
2018-03-15 17:02               ` Waiman Long
     [not found]                 ` <047c6ed6-6581-b543-ba3d-cadc543d3d25-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2018-03-15 19:00                   ` Eric W. Biederman
2018-03-15 19:00                     ` Eric W. Biederman
     [not found]                     ` <87h8ph6u67.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2018-03-15 21:46                       ` Waiman Long
2018-03-15 21:46                         ` Waiman Long
     [not found]                         ` <7d3a1f93-f8e5-5325-f9a7-0079f7777b6f-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2018-03-29  2:14                           ` Davidlohr Bueso
2018-03-29  2:14                             ` Davidlohr Bueso
2018-03-29  8:47                             ` Manfred Spraul
2018-03-29 10:56                               ` Matthew Wilcox
     [not found]                                 ` <20180329105601.GA597-PfSpb0PWhxZc2C7mugBRk2EX/6BAtgUQ@public.gmane.org>
2018-03-29 18:07                                   ` Manfred Spraul
2018-03-29 18:07                                     ` Manfred Spraul
2018-03-29 18:52                                     ` Eric W. Biederman
     [not found]                                     ` <05772f83-d680-aea1-b222-cef2430dcc83-nhLOkwUX5cPe2c5cEj3t2g@public.gmane.org>
2018-03-29 18:52                                       ` Eric W. Biederman
2018-03-29 19:32                                       ` Matthew Wilcox
2018-03-29 19:32                                     ` Matthew Wilcox
2018-03-29 20:08                               ` Eric W. Biederman
     [not found]                               ` <3e201de2-bed2-6f7d-0783-700d095142e0-nhLOkwUX5cPe2c5cEj3t2g@public.gmane.org>
2018-03-29 10:56                                 ` Matthew Wilcox
2018-03-29 20:08                                 ` Eric W. Biederman
2018-03-29  8:47                             ` Manfred Spraul
2018-03-15 19:45               ` Matthew Wilcox
2018-03-12 20:15 ` [PATCH v4 5/6] ipc: Clamp semmni to the real IPCMNI limit Waiman Long
2018-03-12 20:52   ` Luis R. Rodriguez
2018-03-12 20:59     ` Waiman Long
2018-03-12 20:15 ` [PATCH v4 6/6] test_sysctl: Add range clamping test Waiman Long
2018-03-12 20:53   ` Luis R. Rodriguez
2018-03-12 21:00     ` Waiman Long

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=20180312205920.GD4449@wotan.suse.de \
    --to=mcgrof@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=keescook@chromium.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=longman@redhat.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=willy@infradead.org \
    /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.