From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 37123 invoked by alias); 15 Mar 2018 20:03:07 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 37112 invoked by uid 89); 15 Mar 2018 20:03:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=talk X-HELO: out02.mta.xmission.com From: ebiederm@xmission.com (Eric W. Biederman) To: Christian Brauner Cc: libc-alpha@sourceware.org References: <20180315120651.14107-1-christian.brauner@ubuntu.com> Date: Thu, 15 Mar 2018 20:03:00 -0000 In-Reply-To: <20180315120651.14107-1-christian.brauner@ubuntu.com> (Christian Brauner's message of "Thu, 15 Mar 2018 13:06:51 +0100") Message-ID: <87efkl3y61.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=1ewZ5a-0006Hi-AF;;;mid=<87efkl3y61.fsf@xmission.com>;;;hst=in01.mta.xmission.com;;;ip=97.119.121.173;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1/SXR1EytNkze1383z/iQcKbPwwKh+OcLU= X-SA-Exim-Connect-IP: 97.119.121.173 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 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 * [sa08 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa08 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Christian Brauner X-Spam-Relay-Country: X-Spam-Timing: total 287 ms - load_scoreonly_sql: 0.03 (0.0%), signal_user_changed: 2.6 (0.9%), b_tie_ro: 1.79 (0.6%), parse: 0.72 (0.3%), extract_message_metadata: 12 (4.2%), get_uri_detail_list: 1.10 (0.4%), tests_pri_-1000: 12 (4.1%), tests_pri_-950: 1.04 (0.4%), tests_pri_-900: 0.98 (0.3%), tests_pri_-400: 24 (8.3%), check_bayes: 23 (8.0%), b_tokenize: 4.3 (1.5%), b_tok_get_all: 11 (3.7%), b_comp_prob: 1.62 (0.6%), b_tok_touch_all: 2.1 (0.7%), b_finish: 0.64 (0.2%), tests_pri_0: 228 (79.5%), check_dkim_signature: 0.38 (0.1%), check_dkim_adsp: 10 (3.6%), tests_pri_500: 3.7 (1.3%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH] getpt: use /dev/pts/ptmx as default ptmx master 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) X-SW-Source: 2018-03/txt/msg00385.txt.bz2 Christian Brauner writes: > For a long time now Linux has placed the ptmx character device directly > under the devpts mount at /dev/pts/ptmx. The /dev/ptmx path today is > usually either a symlink, an additional character device or a bind-mount. > > The idea has always been to slowly fade-out /dev/ptmx and switch to using > /dev/pts/ptmx exclusively. The kernel currently maintains code to retain > backwards compatibility for anyone going through /dev/ptmx. It depends on who you talk to Linus is against the slow fade-out. > Specifically, if the ptmx device is opened through /dev/ptmx the kernel > will look for a "pts" directory in the same directory where the /dev/ptmx > device node resides. This implies that the devpts mount at /dev/pts and the > /dev/ptmx mount need to have a common ancestor directory. This assumption > is usually fulfilled when a symlink or separate device node is used. > However, this assumption will be broken when /dev/ptmx is a bind-mount of > /dev/pts/ptmx because they are located on different devices. For a detailed > analysis of this problem please refer to my upstream patch [1]. We just finished merging the patches that causes this to be a problem for TIOCGTPEER. > It is time to start switching to using /dev/pts/ptmx and use /dev/ptmx as a > fallback only. As far as I can tell, we have three cases to reason > about: If we had always had /dev/pts/ptmx there definitely would have been advantages. What advantages does it have now to switch to opening /dev/pts/ptmx? Especially given that the default permissions are 0000, so opening /dev/pts/ptmx will fail on most ordinary configurations today. Only in containers is /dev/pts/ptmx the prefered device to open. There is a strong argument for using TIOCGTPEER (this fixes possible races). There is a strong argument for having each mount of devpts be a distinct filesystem (this fixes mount options from a chroot b0rking the main system). I don't see a similarly strong argument for asking glibc to always open /dev/pts/ptmx if available. It would simplify things, but we have already dealt with the issues. So I don't see any real world issues that it fixes. Eric