From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 90178 invoked by alias); 15 Mar 2018 14:49:04 -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 90155 invoked by uid 89); 15 Mar 2018 14:49:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.7 required=5.0 tests=AWL,BAYES_00,FSL_HELO_FAKE,KAM_LAZY_DOMAIN_SECURITY,KAM_SHORT,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=dO1MTy8J32klJ/gCiAg6oQYLgGBwLxKldcZuRlaoi3k=; b=GZ8f9A83uyJNaqUrys+ilGb3mlpx1DkRhr8Qr6VxOSht3Lomd/24xBllsTtx0kGij4 1J9bA6yMOaoYjgBapsYSfFDA7xPiHSve9fgYXDqm/B2GL08QLytTuWzYNV7e2XZeCZsl 1GG8pwOtjNMz3JLS+LhwZmzDuRlTnvjeBVMgXSHml8M8oRmJMpeqR2nWL4ljiY8wShoX DqZ2SNAVpfYkvkW0yRBTQQZLZgWdicIqqzkAQD7rB5uJh1sv8voxPpG4TihP0fi44JCz eyAq2qAKvhssKwEIfIdLSXHZjJCWT8B0hHOz5uMhhvLe8TsBAstXWYsuHtu7O34yFPoo WBPg== X-Gm-Message-State: AElRT7E7ZPxO7MGC44b/N75YiVRFFria/gsersOY74LPhmfXkHkpmSwK REyChAX5lDnxL3PQjVqjmsT+Fmh9yRSKN9TD8zInFj1spwFZY6M9ve4IvunFVq9YoM8ot9fnhUa nedIYSSIUFdeOmL3ecch9EomwZkDP4XWUEsDl2w== X-Received: by 10.28.195.68 with SMTP id t65mr2968632wmf.40.1521125339552; Thu, 15 Mar 2018 07:48:59 -0700 (PDT) X-Google-Smtp-Source: AG47ELtyfo4eZCfuv1HgAhaSaxkeKmK0HW5maADt4+JTvZSFk5z+OwnOYoutZJ8i/V9uaR0Bf40YAw== X-Received: by 10.28.195.68 with SMTP id t65mr2968616wmf.40.1521125339301; Thu, 15 Mar 2018 07:48:59 -0700 (PDT) Date: Thu, 15 Mar 2018 14:49:00 -0000 From: Christian Brauner To: Zack Weinberg Cc: Christian Brauner , ebiederm@xmission.com, GNU C Library Subject: Re: [PATCH] getpt: use /dev/pts/ptmx as default ptmx master Message-ID: <20180315144856.GA12217@gmail.com> References: <20180315120651.14107-1-christian.brauner@ubuntu.com> <20180315141046.GA15486@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-SW-Source: 2018-03/txt/msg00372.txt.bz2 On Thu, Mar 15, 2018 at 10:38:07AM -0400, Zack Weinberg wrote: > On Thu, Mar 15, 2018 at 10:10 AM, Christian Brauner > wrote: > > On Thu, Mar 15, 2018 at 10:02:56AM -0400, Zack Weinberg wrote: > >> On Thu, Mar 15, 2018 at 8:06 AM, Christian Brauner > >> wrote: > >> > For a long time now Linux has placed the ptmx character device directly > >> > under the devpts mount at /dev/pts/ptmx. > >> > >> Exactly which kernel version started doing this? > > > > The article about the patch is here. > > https://lwn.net/Articles/689539/ > > I'm afraid I don't know how to work out from that article which > _release version_ of the kernel first provided ptmx inside devpts. > > However, that's dated 2016 and the oldest kernel that glibc still > supports for runtime use is 3.2, which came out in 2012, so I conclude > we do need the fallback code, at least. > > >> > It is time to start switching to using /dev/pts/ptmx and use /dev/ptmx as a > >> > fallback only. > >> > >> Application code is entitled to do open ('/dev/ptmx", O_RDWR) itself > >> rather than calling posix_openpt. It is not OK to break those > >> applications. That was the recommended practice prior to the > >> introduction of posix_openpt, and I am suspicious of posix_openpt not > >> existing on still-reasonable portability targets. > >> > >> Since /dev/ptmx must stick around for the sake of those applications, > >> I am inclined to say that libc's posix_openpt should continue using > >> /dev/ptmx as well, in order to ensure that that configuration > >> continues to be tested. I am also inclined to say that, on new > >> kernels where the devpts filesystem provides the ptmx node, using a > >> bind-mount rather than a symlink for /dev/ptmx is a misconfiguration > >> (and on older kernels, obviously it needs to be an actual device > >> node). > > > > Neither the kernel nor this patch breaks userspace applications. Maybe > > I'm being dense but what argument supports this assumption? > > This patch extends __posix_openpt() to try and open(/dev/pts/ptmx) first > > and if it fails for any reason retry with open(/dev/ptmx). > > Sorry, I was unclear. > > The scenario I want to avoid is, five to ten years in the future, > someone - perhaps a sloppy container constructor - thinks that > /dev/ptmx can be dropped. This is not OK, even that far ahead, > because it might break applications. In order to prevent that from > happening, I think glibc should continue to use only /dev/ptmx, so > that the breakage will be immediate and obviously the fault of the > sloppy container constructor. By that logic adding superseeding features should never be supported because of the possibility that someone might *accidently* drop support for the legacy version. That doesn't make sense. Dropping /dev/ptmx will not happen and is not intended. If that's the core of the concern we can put a comment in there statig explictly "Never ever remove the fallback as we support old kernels that do not have /dev/pts/ptmx." Furthermore, such fallbacks exist in multiple locations in glibc already. One recent example is that glibc already supports the TIOCGPTPEER ioctl() call to allocate the slave side file descriptor of a pty solely on the master fd and uses unsafe path-based retrieval only as a fallback option. Nothing in that patch implies that path-based retrieveal will ever be removed. Neither does anything in this patch imply that /dev/ptmx will. Christian > > I have no objection to your _kernel_ patch, I just think it's silly to > use a bind-mount for /dev/ptmx when a symlink will work just as well > (in fact, better). > > zw