From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 113113 invoked by alias); 15 Mar 2018 20:12:03 -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 113103 invoked by uid 89); 15 Mar 2018 20:12:03 -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,FSL_HELO_FAKE,KAM_LAZY_DOMAIN_SECURITY,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy= X-HELO: youngberry.canonical.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=KmNDvIRZ6v6oQDbLmoEl0XdM5ZvYC42wMGCFvnozsaY=; b=CO4ivnderBVgS0S2xT6PB85SJ6kLh8TlxeR83BZQ6k4vef/s3j4lT9l1IwYRSAW9wn 9L66IjrgJY3OKuI6OGCrPcdTrjoLyEb+DV206vP2tTC8mtK9TMlFEBZ67wPetqbccvYA sb0HT9ZNVk+LCsYes3WP/60kAwztghcqjMqLtvgHW4dJPF+gOHxBxNpKvA2GHcjjih5x TktB5hv2t3Y4XOlDjHSQ2nfxnpIJhsy/gBkVNZ6PT4fQjhR03FZqd4jEKNt/Trm2gUUh iXEn9ny8H1tuTl51Ts13Si4J7CIBpKrZk59BxSdVXUeEpUBAbP1phG4119radRf3XFr+ eH4Q== X-Gm-Message-State: AElRT7Ho8kh9w155kfQBGb4/gYznvlmrnVQOPk0dgoGNEbBZywTxMytM f3JD7whIupc87RHigpILYn6FrBdO5Zw0ByFBRaAvw6VjFbJvmXc1elCGAgS0rzJ7rEDf++EPhAi 5xvRKIcIwqH1hRfZyTgqCb+wBHC0rhGrUhKVMGQ== X-Received: by 10.28.38.193 with SMTP id m184mr2911709wmm.11.1521144719656; Thu, 15 Mar 2018 13:11:59 -0700 (PDT) X-Google-Smtp-Source: AG47ELuwc4NPEMB7LSKvkTHm7lWjFFp3hVFoFlT38hWc5whj1Z1CuLONgETZquu+uCkEp0CImK/iLQ== X-Received: by 10.28.38.193 with SMTP id m184mr2911698wmm.11.1521144719357; Thu, 15 Mar 2018 13:11:59 -0700 (PDT) Date: Thu, 15 Mar 2018 20:12:00 -0000 From: Christian Brauner To: "Eric W. Biederman" Cc: Christian Brauner , libc-alpha@sourceware.org Subject: Re: [PATCH] getpt: use /dev/pts/ptmx as default ptmx master Message-ID: <20180315201156.GA7966@gmail.com> References: <20180315120651.14107-1-christian.brauner@ubuntu.com> <87efkl3y61.fsf@xmission.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87efkl3y61.fsf@xmission.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-SW-Source: 2018-03/txt/msg00386.txt.bz2 On Thu, Mar 15, 2018 at 03:02:14PM -0500, Eric W. Biederman wrote: > 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. Thanks for stopping by Eric, if you think it's not worth it I'm not going to pursue this further. My main reason for pushing the /dev/pts/ptmx first, /dev/ptmx second was that all bugs we ever had that caused /proc//fd/ symlinks to be messed were caused by going through /dev/ptmx causing the kernel to go through "needless" lookup logic in case the devpts filesystem couldn't immediately be found where the ptmx device was. Christian