Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753684AbdHXUn5 (ORCPT ); Thu, 24 Aug 2017 16:43:57 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:55786 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752875AbdHXUn4 (ORCPT ); Thu, 24 Aug 2017 16:43:56 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Linus Torvalds Cc: Christian Brauner , Al Viro , Serge Hallyn , Stefan Lippers-Hollmann , Christian Brauner , Thorsten Leemhuis , Linux Kernel Mailing List References: <20170816171211.4021-1-christian.brauner@ubuntu.com> <87pobvruzt.fsf@xmission.com> <87ziazqdfr.fsf@xmission.com> <20170824022436.44adb497@mir> <87378hhi3y.fsf@xmission.com> <87wp5tfynr.fsf@xmission.com> <20170824062432.1e05e6f8@mir> <874lsxezal.fsf@xmission.com> <87y3q8ermg.fsf@xmission.com> Date: Thu, 24 Aug 2017 15:43:32 -0500 In-Reply-To: (Linus Torvalds's message of "Thu, 24 Aug 2017 12:22:19 -0700") Message-ID: <874lswae8b.fsf@xmission.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1dkyyi-0006DA-9O;;;mid=<874lswae8b.fsf@xmission.com>;;;hst=in01.mta.xmission.com;;;ip=67.3.200.44;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1/24g11mxJZefIKzPNoJYyxZR1kBDw4Xs0= X-SA-Exim-Connect-IP: 67.3.200.44 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 1.5 XMNoVowels Alpha-numberic number with no vowels * 0.7 XMSubLong Long Subject * 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 * [sa07 1397; Body=1 Fuz1=1 Fuz2=1] * 0.0 T_TooManySym_01 4+ unique symbols in subject * 0.0 T_TooManySym_02 5+ unique symbols in subject * 0.0 T_TooManySym_03 6+ unique symbols in subject X-Spam-DCC: XMission; sa07 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: **;Linus Torvalds X-Spam-Relay-Country: X-Spam-Timing: total 5546 ms - load_scoreonly_sql: 0.03 (0.0%), signal_user_changed: 2.5 (0.0%), b_tie_ro: 1.77 (0.0%), parse: 0.87 (0.0%), extract_message_metadata: 19 (0.3%), get_uri_detail_list: 2.1 (0.0%), tests_pri_-1000: 13 (0.2%), tests_pri_-950: 1.69 (0.0%), tests_pri_-900: 1.39 (0.0%), tests_pri_-400: 30 (0.5%), check_bayes: 29 (0.5%), b_tokenize: 10 (0.2%), b_tok_get_all: 9 (0.2%), b_comp_prob: 2.9 (0.1%), b_tok_touch_all: 4.4 (0.1%), b_finish: 0.57 (0.0%), tests_pri_0: 209 (3.8%), check_dkim_signature: 0.53 (0.0%), check_dkim_adsp: 3.1 (0.1%), tests_pri_500: 5264 (94.9%), poll_dns_idle: 5259 (94.8%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH 0/1] devpts: use dynamic_dname() to generate proc name X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -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: 3090 Lines: 79 Linus Torvalds writes: > On Thu, Aug 24, 2017 at 12:01 PM, Christian Brauner > wrote: >> >> I've touched on this in my original message, I wonder whether we currently >> support mounting devpts at a different a location and expect an open on a >> newly created slave to work. > > Yes. That is very much intended to work. > >> Say I mount devpts at /mnt and to open("/mnt/ptmx", O_RDWR | O_NOCTTY) and get a new slave pty at /mnt/1 do we >> expect open("/mnt/1, O_RDWR | O_NOCTTY) to work? > > Yes. > > Except you actually don't want to use "/mnt/ptmx". That ptmx node > inside the pts filesystem is garbage that we never actually used, > because the permissions aren't sane. It should probably be removed, > but because somebody *might* have used it, we have left it alone. The ptmx node on devpts is used. Use of that device node is way more prevalent then crazy weird cases that required us to make /dev/ptmx perform relative lookups. People just set the ptmxmode= boot parameter when mounting devpts if they care. Every use case I am aware of where people actually knew about multiple instances of devpts used the ptmx node in the devpts filesystem. If everyone used devtmpfs we could have fixed the permissions on the ptmx node in devpts and made /dev/ptmx a symlink instead of a device node. Saving lots of complexity. Unfortunately there were crazy weird cases out there where people created chroots or mounted devpts multiple times during boot that defeated every strategy except making /dev/ptmx perform a relative lookup for devpts. The reasons I did not fix the permissions on the ptmx deivcd node was that given the magnitude of the change needed to get to the sensible behavior of every mount of devpts creating a new filesystem, any unnecessary changes were just plain scary. Further the kind of regression that would be introduced if we changed the permissions would be a security hole if someone has some really weird and crazy permissions on /dev/ptmx and does not use devtmpfs. That said I could not find a distribution being that crazy and I had a very good sample of them. So I expect we can fix the default permissions on ptmx node of devpts and not have anyone notice or care. I would encourage people who are doing new things to actually use the ptmx node on devpts because there is less overhead and it is simpler. There are just enough weird one off scripts like xen image builder (I think that was the nasty test case that broke in debian) that I can't imagine ever being able to responsibly remove the path based lookups in /dev/ptmx. I do dream of it sometimes. It might be worth fixing the default permissions on the devpts ptmx node and updating glibc to try /dev/pts/ptmx first. That would shave off a few cycles in opening ptys. If you add TIOCGPTPEER there are probably enough cleanups and simplifications that it would be worth it just for the code improvements. With glibc fixed we could even dream of a day when /dev/ptmx could be completely removed. Eric