Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754312AbdHZBAk (ORCPT ); Fri, 25 Aug 2017 21:00:40 -0400 Received: from mail-oi0-f65.google.com ([209.85.218.65]:33819 "EHLO mail-oi0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751453AbdHZBAi (ORCPT ); Fri, 25 Aug 2017 21:00:38 -0400 MIME-Version: 1.0 In-Reply-To: <20170824233737.umna3s7vsbuv6oi6@gmail.com> References: <874lsxezal.fsf@xmission.com> <87y3q8ermg.fsf@xmission.com> <874lswae8b.fsf@xmission.com> <877exs7epb.fsf@xmission.com> <20170824233737.umna3s7vsbuv6oi6@gmail.com> From: Linus Torvalds Date: Fri, 25 Aug 2017 18:00:35 -0700 X-Google-Sender-Auth: p3lu8PtNK5VhWNRuO9LyKUfjNS8 Message-ID: Subject: Re: [PATCH 0/1] devpts: use dynamic_dname() to generate proc name To: Christian Brauner Cc: "Eric W. Biederman" , Al Viro , Serge Hallyn , Stefan Lippers-Hollmann , Christian Brauner , Thorsten Leemhuis , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1642 Lines: 40 On Thu, Aug 24, 2017 at 4:37 PM, Christian Brauner wrote: > > In fact, /dev/ptmx being a symlink or bind-mount is the *standard* in containers > even for non-user namespaced containers or containers that do not retain > CAP_MKNOD. Yes. I think using /dev/pts/ptmx is nice from a kernel standpoint, but I really think that user space should *never* use it. The distro or container setup can do whatever it wants to made /dev/ptmx then point into the pts directory. Either the traditional device node, the symlink, or the bind mount works fine. But the point is that glibc definitely should *not* point to /dev/pts/ptmx itself, because it's simply not the right path. On lots of distributions that path simply will not work. And yes, I agree that the user interface to this all is particularly nasty. With TIOCGPTPEER we have a nice way to get the pts file descriptor, but the "normal" way to get to it involves opening a path given by ptsname(), so we en dup in the crazy situation that we can easily open the file without the path, but then we use the fd to get the path (that we didn't need) and then people open it with that path, because the standard sequence to get a pts is master = getpt() / posix_openpt() / open("/dev/ptmx", O_RDWR | O_NOCTTY); grantpt(master); unlockpt(master); name = ptsname(master); slave = open(name, O_RDWR); which is kind of silly. And I'm not talking about the three different ways to open the master side. I'm talking about all the rest, which is all just pretty much garbage. But I guess none of this is really performance-critical. Linus