Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755191AbbLKW5c (ORCPT ); Fri, 11 Dec 2015 17:57:32 -0500 Received: from thejh.net ([37.221.195.125]:42459 "EHLO thejh.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754890AbbLKW51 (ORCPT ); Fri, 11 Dec 2015 17:57:27 -0500 Date: Fri, 11 Dec 2015 23:58:25 +0100 From: Jann Horn To: Andy Lutomirski Cc: "Eric W. Biederman" , "H. Peter Anvin" , Al Viro , Greg KH , Jiri Slaby , Linus Torvalds , Aurelien Jarno , Florian Weimer , Serge Hallyn , "security@kernel.org" , "security@ubuntu.com >> security" , security@debian.org, Willy Tarreau , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] devpts: Sensible /dev/ptmx & force newinstance Message-ID: <20151211225825.GA24676@pc.thejh.net> References: <20151209013859.GA12442@kroah.com> <20151209083225.GA30452@1wt.eu> <87wpskyds7.fsf_-_@x220.int.ebiederm.org> <20151211210400.GL20997@ZenIV.linux.org.uk> <87h9jovgf7.fsf@x220.int.ebiederm.org> <566B4931.5080806@zytor.com> <87y4d0sjff.fsf@x220.int.ebiederm.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Q68bSM7Ycu6FN28Q" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3741 Lines: 92 --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 11, 2015 at 02:52:01PM -0800, Andy Lutomirski wrote: > On Fri, Dec 11, 2015 at 2:35 PM, Eric W. Biederman > wrote: > > Andy Lutomirski writes: > > > >> On Fri, Dec 11, 2015 at 2:07 PM, H. Peter Anvin wrote: > >>> On 12/11/15 13:48, Andy Lutomirski wrote: > >>>> On Fri, Dec 11, 2015 at 1:11 PM, Eric W. Biederman > >>>> wrote: > >>>>> Al Viro writes: > >>>>> > >>>>>> On Fri, Dec 11, 2015 at 01:40:40PM -0600, Eric W. Biederman wrote: > >>>>>> > >>>>>>> + inode =3D path.dentry->d_inode; > >>>>>>> + filp->f_path =3D path; > >>>>>>> + filp->f_inode =3D inode; > >>>>>>> + filp->f_mapping =3D inode->i_mapping; > >>>>>>> + path_put(&old); > >>>>>> > >>>>>> Don't. You are creating a fairly subtle constraint on what the co= de in > >>>>>> fs/open.c and fs/namei.c can do, for no good reason. You can bloo= dy > >>>>>> well maintain the information you need without that. > >>>>> > >>>>> There is a good reason. We can not write a race free version of pt= sname > >>>>> without it. > >>>> > >>>> As long as this is for new userspace code, would it make sense to ju= st > >>>> add a new ioctl to ask "does this ptmx fd match this /dev/pts fd?" > >>>> > >>> > >>> For the newinstance case st_dev should match between the master and t= he > >>> slave. Unfortunately this is not the case for a legacy ptmx, as a > >>> stat() on the master descriptor still returns the st_dev, st_rdev, and > >>> st_ino for the ptmx device node. > >> > >> Sure, but I'm not talking about stat. I'm saying that we could add a > >> new ioctl that works on any ptmx fd (/dev/ptmx or /dev/pts/ptmx) that > >> answers the question "does this ptmx logically belong to the given > >> devpts filesystem". > >> > >> Since it's not stat, we can make it do whatever we want, including > >> following a link to the devpts instance that isn't f_path or f_inode. > > > > The useful ioctl to add in my opinion would be one that actually opens > > the slave, at which point ptsname could become ttyname, and that closes > > races in grantpt. >=20 > Unfortunately, ptsname is POSIX, so we can't get rid of it. It's a > bad idea, but it's in the standard. But then ptsname could become "open the slave, call ttyname() on it, close the slave". Unless opening the slave would have side effects? --Q68bSM7Ycu6FN28Q Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJWa1URAAoJED4KNFJOeCOobFQQALno+y85bcqxIEgXdCleKq2v udqs7hQZ66Im5+Ybo31F2aDGBPlbkhgRYrHbC3fCLSLYFnRfoxNWhuQ0JLWMFRMg EqdlIuN5UVjcVZUcQn5GK5Hh97QrdFcXCcOhXIZEalKd7H5+xNOJaANyP6vI8uUj 88wRoSHUqpB0B9V0GlUwTHuPczSPzkYvLK+gsFqabyU+68zLbPCNKXZYJDxT6/Cd p0YcrRDtGPkIdIsEr0jlGIRPKto5cOmWiyFEvDuepi1BylqgVo3tB1CQkGcd+0Qd 11stW6M61KRzX+DjwThi1m0MhfCAx+efr9CY3sHgh8qvygWxCxxMI8HGFlUcPlWx jLjDvsmcrPK0xjVgkrrYiZC4zF9S/vmPvlIPjipN8kFq2yCAZS+JeHlOe3Tlw+Ku Z64OgnePSPBpyG0dWSK9HnCxdRyzqXhjqRnw5WFDAi+i8GZR6xeJYUAioq3Un4ai /uKaQ6bCq3xai7qerIoDo34uqxOiYb5/lLA+SnfISK0pESV6C5mQPz5q9Cs5UVhR CL1SWA4FPppvJ+q+zdZtLdbwipaTSN6PICYqnzdDU6losYzeAn8MV/VJuwkiso0C wHAIj/ZgE6R30ZVcBfaxsDmlKH8PN29CbBUz1kCh1Z8R6IpDsqRwHofYLoa0yrjA o4wmIqywZYhTAyJ17upA =AWYG -----END PGP SIGNATURE----- --Q68bSM7Ycu6FN28Q-- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/