Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932881AbcDST2Q (ORCPT ); Tue, 19 Apr 2016 15:28:16 -0400 Received: from terminus.zytor.com ([198.137.202.10]:42608 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753985AbcDST2P (ORCPT ); Tue, 19 Apr 2016 15:28:15 -0400 User-Agent: K-9 Mail for Android In-Reply-To: <87inzdju98.fsf@x220.int.ebiederm.org> 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> 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:25:03 -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: <87C89963-F554-481F-81FF-5DC395062943@zytor.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1194 Lines: 30 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. -- Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.