Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755035AbcDKUQQ (ORCPT ); Mon, 11 Apr 2016 16:16:16 -0400 Received: from out01.mta.xmission.com ([166.70.13.231]:59056 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752199AbcDKUQO (ORCPT ); Mon, 11 Apr 2016 16:16:14 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Linus Torvalds Cc: "H. Peter Anvin" , One Thousand Gnomes , 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 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> <78205895-E11D-417F-91DC-4BCA0B61A122@zytor.com> Date: Mon, 11 Apr 2016 15:05:21 -0500 In-Reply-To: (Linus Torvalds's message of "Sat, 9 Apr 2016 17:01:27 -0700") Message-ID: <87bn5fgbcu.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-AID: U2FsdGVkX19RIKXNoh4Bas554aZ9b19iyUYT+L2XBTk= X-SA-Exim-Connect-IP: 67.3.249.252 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.7 XMSubLong Long Subject * 1.5 XMNoVowels Alpha-numberic number with no vowels * 0.0 TVD_RCVD_IP Message was received from an IP address * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa01 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa01 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: **;Linus Torvalds X-Spam-Relay-Country: X-Spam-Timing: total 1150 ms - load_scoreonly_sql: 0.06 (0.0%), signal_user_changed: 10 (0.9%), b_tie_ro: 2.8 (0.2%), parse: 1.29 (0.1%), extract_message_metadata: 30 (2.6%), get_uri_detail_list: 3.6 (0.3%), tests_pri_-1000: 12 (1.0%), tests_pri_-950: 1.98 (0.2%), tests_pri_-900: 1.64 (0.1%), tests_pri_-400: 42 (3.7%), check_bayes: 40 (3.5%), b_tokenize: 17 (1.5%), b_tok_get_all: 11 (0.9%), b_comp_prob: 5 (0.5%), b_tok_touch_all: 3.2 (0.3%), b_finish: 0.82 (0.1%), tests_pri_0: 721 (62.7%), check_dkim_signature: 0.86 (0.1%), check_dkim_adsp: 113 (9.8%), tests_pri_500: 324 (28.2%), poll_dns_idle: 314 (27.3%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH 01/13] devpts: Teach /dev/ptmx to find the associated devpts via path lookup X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Wed, 24 Sep 2014 11:00:52 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2573 Lines: 59 Linus Torvalds writes: > On Sat, Apr 9, 2016 at 3:37 PM, H. Peter Anvin wrote: >> >> 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. > > You don't need a different device number. > > The /dev/pts/ptmx file may look like it's the same node as /dev/ptmx, > but it is trivial to recognize as the pts one: > > if (dentry->d_sb->s_magic == DEVPTS_SUPER_MAGIC) > > and you're done. We can actually do better and set f_ops in devpts and bypass the whole lookup by device number. In my pile of cleanups that are waiting for the mess to resolve I actually have a patch that does that for the slave ttys. > > But nobody actually uses /dev/pts/ptmx, because it has never had sane > permissions. Now that is an interesting misconception to see. There is actually a lot more software that uses /dev/pts/ptmx (with a symlink from /dev/ptmx or a bind mount to /dev/ptmx) than there is that actually needs the new compatibility behavior. Carefully written and maintained container software like lxc and docker do use "-o newinstance". Fixing the permissions and redirecting the /dev/ptmx path to /dev/pts/ptmx are not a problem when you know you are setting up a special environment. It is the one off sloppily created automation scripts like xen-create-image that gets this wrong. I say sloppily created as in practice every mount of devpts needs "-o gid=5,mode=620". If xen-create-image and related software had gotting those mount options correct pt_chown could have been done away with, with no one noticing a long time ago. Those sloppy pieces of code are probably the things we want to break least as they work after their fasion and whoever wrote them is likely long gone. So I would be surprised if there was anyone to pick up the pieces if we break them. > But when we fix bad semantics (and always just looking up the initial > pts mount really is crazy semantics) that doesn't mean that we have to > bend over backwards to not make the changed semantics visible. We > don't _break_ user space, but we also don't care about some random > test-program that checks for particular semantics. No. Bending over backwards as you call it just makes the software test matrix smaller. That part is now settled in my book and those extra permission checks will not be in the next version of this patchset. Eric