Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933015AbcDST3b (ORCPT ); Tue, 19 Apr 2016 15:29:31 -0400 Received: from terminus.zytor.com ([198.137.202.10]:42620 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932673AbcDST3a (ORCPT ); Tue, 19 Apr 2016 15:29:30 -0400 User-Agent: K-9 Mail for Android In-Reply-To: <87C89963-F554-481F-81FF-5DC395062943@zytor.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> 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: Tue, 19 Apr 2016 12:26:19 -0700 To: ebiederm@xmission.com 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 Content-Length: 1451 Lines: 37 On April 19, 2016 12:25:03 PM PDT, "H. Peter Anvin" wrote: >On April 19, 2016 12:03:47 PM PDT, ebiederm@xmission.com wrote: >>"H. Peter Anvin" writes: >> >>>>- Support for reserving ptys for the system devpts instance using >>>> /proc/sys/kernel/pty/reserve needs to be removed. >>>> >>>>Eric >>> >>> pty capping should probably be a devpts mount option >> >>There is a max option so pty capping is a per devpts option. >> >>> , and perhaps a >>> sufficiently privileged user could be allowed to set another mount >>> option to allow that instance to dip into the reserved pool or >exempt >>> it completely from the global limit as set in sysctl. >> >>I agree that we could keep the reserved pool, and add a new way to >>access it. However no piece of existing userspace could use it. So >>the >>simplest thing to do (unless something actually breaks), is to just >>remove the reserve pool. >> >>Eric > >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. -- Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.