Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751485AbcDIWqK (ORCPT ); Sat, 9 Apr 2016 18:46:10 -0400 Received: from [198.137.202.10] ([198.137.202.10]:60952 "EHLO mail.zytor.com" rhost-flags-FAIL-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1751059AbcDIWqJ (ORCPT ); Sat, 9 Apr 2016 18:46:09 -0400 User-Agent: K-9 Mail for Android In-Reply-To: <87bn5ij0x1.fsf@x220.int.ebiederm.org> References: <878u0s3orx.fsf_-_@x220.int.ebiederm.org> <1459819769-30387-1-git-send-email-ebiederm@xmission.com> <87twjcorwg.fsf@x220.int.ebiederm.org> <20160409140909.42315e6d@lxorguk.ukuu.org.uk> <83FE8CD2-C0A2-4ADB-AEBD-8DD89AD4F88A@zytor.com> <87bn5ij0x1.fsf@x220.int.ebiederm.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Subject: Re: [PATCH 01/13] devpts: Teach /dev/ptmx to find the associated devpts via path lookup From: "H. Peter Anvin" Date: Sat, 09 Apr 2016 15:37:55 -0700 To: ebiederm@xmission.com CC: One Thousand Gnomes , Linus Torvalds , Peter Hurley , Greg KH , Jiri Slaby , Aurelien Jarno , Andy Lutomirski , Florian Weimer , Al Viro , Serge Hallyn , Jann Horn , "security@kernel.org" , "security@ubuntu.com >> security" , security@debian.org, Willy Tarreau , Linux Kernel Mailing List Message-ID: <78205895-E11D-417F-91DC-4BCA0B61A122@zytor.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2373 Lines: 62 On April 9, 2016 7:45:46 AM PDT, ebiederm@xmission.com wrote: >"H. Peter Anvin" writes: > >> On April 9, 2016 6:09:09 AM PDT, One Thousand Gnomes > wrote: >>> >>>> If anyone has a better idea on how userspace should connect the >>>master >>>> pty file descriptor the slave file descriptor, I would be willing >to >>>> implement that instead. >>> >>>If we are willing to go away from the existing mess of a tty >interface >>>inflicted on us by BSD and then mashed up by POSIX then a syscall of >>> >>> int err = ptypair(int fd[2], int perms, int flags); >>> >>>[where flags is the O_ ones we usually need to cover (CLOEXEC etc) >and >>>maybe even some kind of "private" flag to say don't even expose it >via >>>devpts). >>> >>>would do remarkably sane things to the majoirty of use cases as it >>>breaks >>>the dependence on grantpt and also the historic screwup that pty >pairs >>>aren't allocated atomically with both file handles returned as pipe() >>>does. >>> >>>Alan >> >> We don't even need to do that if we'd be willing to change the user >> space interface... if we could rely on the POSIX interface then >> posix_openpt() could simply open /dev/pts/ptmx and everything would >> just work. > >At a quick skim it does look like userspace uses posix_openpt for the >most part. Certainly portable apps that can run on FreeBSD do. >And just grepping through binaries all of the ones I have checked so >far >are calling posix_openpt. > >Peter if you or someone could start updating the userspace version of >posix_openpt to use /dev/pts/ptmx when available over /dev/ptmx in >parallel to the kernel work to always allow mount of devpts to give >distinct instances that would be great. > >> The trick here is how to make it work in the presence of some >> extremely bad practices in existing userspace. > >Yeah. I am going to look and see if I can move this controversial bit >to a separate patch so we can discuss it more conviniently. > >Eric On the flipside, if we were to allow ourselves to break userspace, at this point I would suggest making /dev/pts/ptmx have a different device number and make the legacy /dev/ptmx print a warning message, after which it can at least eventually be deleted. This might not be a bad idea anyway. -- Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.