linux-kernel - Re: [PATCH 0/1] devpts: use dynamic

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CA+55aFxJjhRZRR7TOaVuAGEoncjbgmzfL1QSdgboN3H2=DAO7g@mail.gmail.com>
Date:   Fri, 25 Aug 2017 18:00:35 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Christian Brauner <christian.brauner@...onical.com>
Cc:     "Eric W. Biederman" <ebiederm@...ssion.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        Serge Hallyn <serge@...lyn.com>,
        Stefan Lippers-Hollmann <s.l-h@....de>,
        Christian Brauner <christian.brauner@...ntu.com>,
        Thorsten Leemhuis <regressions@...mhuis.info>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/1] devpts: use dynamic_dname() to generate proc name

On Thu, Aug 24, 2017 at 4:37 PM, Christian Brauner
<christian.brauner@...onical.com> 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