User-Agent: K-9 Mail for Android
In-Reply-To: <57176D1D.70709@gmail.com>
References: <877ffyzy1j.fsf_-_@x220.int.ebiederm.org> <1460734532-20134-1-git-send-email-ebiederm@xmission.com> <1460734532-20134-14-git-send-email-ebiederm@xmission.com> <CA+55aFxzixRgvdfh4KYimgvOpNyZ7Qr1K3Sznea4F7RXmb5vkA@mail.gmail.com> <8737qhpifz.fsf@x220.int.ebiederm.org> <25D92F7D-32F9-4913-9995-2F6B430FA29E@zytor.com> <87inzdju98.fsf@x220.int.ebiederm.org> <87C89963-F554-481F-81FF-5DC395062943@zytor.com> <C99FDB2F-8B26-433E-8CD6-0049D70DD786@zytor.com> <8737qhdknk.fsf@x220.int.ebiederm.org> <57176D1D.70709@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
 charset=UTF-8
Subject: Re: [PATCH 14/16] vfs: Implement mount_super_once
From: "H. Peter Anvin" <hpa@zytor.com>
Date: Wed, 20 Apr 2016 09:12:08 -0700
To: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>,
        "Eric W. Biederman" <ebiederm@xmission.com>
CC: Linus Torvalds <torvalds@linux-foundation.org>,
        Andy Lutomirski <luto@amacapital.net>, security@debian.org,
        "security@kernel.org" <security@kernel.org>,
        Al Viro <viro@zeniv.linux.org.uk>,
        "security@ubuntu.com >> security" <security@ubuntu.com>,
        Peter Hurley <peter@hurleysoftware.com>,
        Serge Hallyn <serge.hallyn@ubuntu.com>, Willy Tarreau <w@1wt.eu>,
        Aurelien Jarno <aurelien@aurel32.net>,
        One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>,
        Jann Horn <jann@thejh.net>, Greg KH <greg@kroah.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Jiri Slaby <jslaby@suse.com>, Florian Weimer <fw@deneb.enyo.de>
Message-ID: <E79284E6-1011-4B25-8B85-58D3F60F60F6@zytor.com>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1347
Lines: 34

On April 20, 2016 4:50:53 AM PDT, "Austin S. Hemmelgarn" <ahferroin7@gmail.com> wrote:
>On 2016-04-19 23:27, Eric W. Biederman wrote:
>> "H. Peter Anvin" <hpa@zytor.com> writes:
>>
>>> On April 19, 2016 12:25:03 PM PDT, "H. Peter Anvin" <hpa@zytor.com>
>wrote:
>>>>
>>>> Perhaps a (privileged) option to exempt from the global limit,
>then.
>>>> Something we can implement if asked for.
>>>>
>>>> However, I wouldn't be 100% that the reserved pool isn't used. 
>Someone
>>>> added it presumably for a reason.  An administrator could say it
>and
>>>> we'd have no idea.
>>>
>>> ... and if I personally was running a container-hosting system, I
>>> would *absolutely* set it to make sure the administrator could not
>get
>>> locked out.
>>
>> That is likely easier done by setting:
>> echo RIDICULOUSLY_LARGE_NUMBER > /proc/sys/kernel/pty/max
>This may protect against administrative lockout on a sane system with 
>responsible users, but it doesn't protect you from lockout due to a DoS
>
>attack, while the reserved pool does (or at least, it makes sure you
>can 
>still allocate a few PTY's even when under attack).

... or even accidental due to some runaway script.  (I may or may not have some first hand knowledge of a similar situation once in college...)
-- 
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.