Received: by 10.213.65.68 with SMTP id h4csp525625imn; Tue, 13 Mar 2018 11:51:14 -0700 (PDT) X-Google-Smtp-Source: AG47ELvpsyHupfGtdjZthgP7kbWvhk6i4vP/N3ZMN97aoSqSQ/0JM3F1SJ38WTI+n3BQ08hdMyLt X-Received: by 10.99.60.79 with SMTP id i15mr1274552pgn.399.1520967074404; Tue, 13 Mar 2018 11:51:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1520967074; cv=none; d=google.com; s=arc-20160816; b=DXBER773bCv2RXIFXAHmAtpB2U+m7HdZS1Gj2ZK1zTEQdD21oQDziTcqoFAqmcrDm3 t51ckj3saFA+VEB1Otqwx70U3IglqRxKjdT9kC6JoV2HTs2iY2zP+7I8bbBw16fm7RbJ JovqLOpgqZxiJnEKijIx4WbPwNCipumt/mBnt74ZVE/mZNL0hUQPgRzyJ9vhlN38506u lJ7PXUxhrnyyCa9DZsYoHSqDut5tYMgrzenYkJEEKgldPmCApKD4PJRyTLQzP3H8upH1 Th9CYnbOSgfowkZFirNiK0LaNojyiEYlJJGgXrS8uzSISdHt7fEfXAK9zgCfnpujBSUU A4Fw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:organization:from:references:cc:to:subject :arc-authentication-results; bh=AsOvQ0HpLPcwU+8aqtYapDelWMo0pV3hmTlan6fV4k0=; b=RVfdvwQwLBxcdxbSWi1hUC2kcrNNxzXBKRScn5oZeNWoKNWfAyEqABfYmiicKuxQCR /NJKnHNzroECGOMCJ6IH5XnShEZ5rMx7ui5/rhcODzRNkZJGqpA1v5IddYx8Wf2P03XA N6bWwXjvo8CSzpQtCWXT/x4FapPIQGlKvXw5DjG5denvD3y1C/4cuW03GSoGDCeU1cvT xLKnpsuUZVCJso16Zj6aDrMTzPXg0dbGGqUkllssTvE91NbXxywFHT5kSGetKbjPpRZ2 4T47CFgNtZsdDNz9S9nCut8xLUWUV5UoAo6Bw3JXr/CzimZmqLqX1xML40qAHGBo6oHf 8Tsg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y7si496634pgy.161.2018.03.13.11.50.59; Tue, 13 Mar 2018 11:51:14 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752555AbeCMSt6 convert rfc822-to-8bit (ORCPT + 99 others); Tue, 13 Mar 2018 14:49:58 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:56254 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752375AbeCMSt4 (ORCPT ); Tue, 13 Mar 2018 14:49:56 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 294038182D2A; Tue, 13 Mar 2018 18:49:56 +0000 (UTC) Received: from llong.remote.csb (ovpn-122-246.rdu2.redhat.com [10.10.122.246]) by smtp.corp.redhat.com (Postfix) with ESMTP id 48EC8215CDA7; Tue, 13 Mar 2018 18:49:55 +0000 (UTC) Subject: Re: [PATCH v4 1/6] sysctl: Add flags to support min/max range clamping To: "Eric W. Biederman" Cc: "Luis R. Rodriguez" , Kees Cook , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Andrew Morton , Al Viro , Matthew Wilcox References: <1520885744-1546-1-git-send-email-longman@redhat.com> <1520885744-1546-2-git-send-email-longman@redhat.com> <87r2onzx4k.fsf@xmission.com> From: Waiman Long Organization: Red Hat Message-ID: <52de4b97-6d97-e91c-3e11-ddbbb7207155@redhat.com> Date: Tue, 13 Mar 2018 14:49:55 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <87r2onzx4k.fsf@xmission.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Content-Language: en-US X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Tue, 13 Mar 2018 18:49:56 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Tue, 13 Mar 2018 18:49:56 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'longman@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/13/2018 01:46 PM, Eric W. Biederman wrote: > Waiman Long writes: > >> When minimum/maximum values are specified for a sysctl parameter in >> the ctl_table structure with proc_dointvec_minmax() handler, update >> to that parameter will fail with error if the given value is outside >> of the required range. >> >> There are use cases where it may be better to clamp the value of >> the sysctl parameter to the given range without failing the update, >> especially if the users are not aware of the actual range limits. >> Reading the value back after the update will now be a good practice >> to see if the provided value exceeds the range limits. > What use cases? Who will break. Examples would be good. See my response to the 4/6 patch. >> To provide this less restrictive form of range checking, a new flags >> field is added to the ctl_table structure. >> >> When the CTL_FLAGS_CLAMP_RANGE flag is set in the ctl_table >> entry, any update from the userspace will be clamped to the given >> range without error if either the proc_dointvec_minmax() or the >> proc_douintvec_minmax() handlers is used. > As this is constructed it will increase the size of ctl_table for > everyone. Better would be to add a new function that behaves similary > but differently than to burden struct ctl_table for the rest of time. If you have concern about increasing the size of the ctl_table, I can revert it back to use unsigned short for flag which will fit into the hole left by the 16-bit mode field. I thought increasing the size of ctl_table a bit isn't a big problem, I may be wrong on that. Adding the new flags field will afford us the ability to better customize the sysctl parameters to different needs that may arise in the future. Cheers, Longman