From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752004AbcDTQPg (ORCPT ); Wed, 20 Apr 2016 12:15:36 -0400 Received: from terminus.zytor.com ([198.137.202.10]:39286 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751933AbcDTQPf (ORCPT ); Wed, 20 Apr 2016 12:15:35 -0400 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> <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> <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" Date: Wed, 20 Apr 2016 09:12:08 -0700 To: "Austin S. Hemmelgarn" , "Eric W. Biederman" CC: Linus Torvalds , Andy Lutomirski , security@debian.org, "security@kernel.org" , Al Viro , "security@ubuntu.com >> security" , Peter Hurley , Serge Hallyn , Willy Tarreau , Aurelien Jarno , One Thousand Gnomes , Jann Horn , Greg KH , Linux Kernel Mailing List , Jiri Slaby , Florian Weimer Message-ID: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On April 20, 2016 4:50:53 AM PDT, "Austin S. Hemmelgarn" wrote: >On 2016-04-19 23:27, Eric W. Biederman wrote: >> "H. Peter Anvin" writes: >> >>> On April 19, 2016 12:25:03 PM PDT, "H. Peter Anvin" >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.