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] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 24 Aug 2017 16:27:29 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>
Cc:     Christian Brauner <christian.brauner@...onical.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:01 PM, Eric W. Biederman
<ebiederm@...ssion.com> wrote:
> Linus Torvalds <torvalds@...ux-foundation.org> writes:
>
>> On Thu, Aug 24, 2017 at 1:43 PM, Eric W. Biederman
>> <ebiederm@...ssion.com> wrote:
>>>
>>> There are just enough weird one off scripts like xen image builder (I
>>> think that was the nasty test case that broke in debian) that I can't
>>> imagine ever being able to responsibly remove the path based lookups in
>>> /dev/ptmx.  I do dream of it sometimes.
>>
>> Not going to happen.
>
> Which is what I said.

Yes, but you then went on to say that we should encourage "/dev/pts/ptmx"

Which is BS.

It's not a standard location, and it doesn't have any advantages.

It was a bad idea and due to a bad implementation. We fixed it. Let it go.

>> The fact is, /dev/ptmx is the simply the standard location.
>> /dev/pts/ptmx simply is *not*.
>
> The standard is posix_openpt().  That is a syscall on the bsds.
> Opening something called ptmx at this point is a Linuxism.

Bzzt. Thank you for playing, but you're completely and utterly wrong.

Look around a bit more.

posix_openpt() may be what you *wish* the standard was, but no,
/dev/ptmx is not a linuxism.

Really. It's the SysV STREAMS standard location, and it is what Sysv
pty users _will_ use directly.

Linux didn't make up that name.

Solaris, HP-UX-11, other sysv code bases all use /dev/ptmx

The whole "posix_openpt()" thing came later, in an attempt to just
unify the BSD and Sysv models.

Just google for "streams pty" if you don't believe me.

So really. The only linuxism here is that stupid /dev/pts/ptmx.

> There are a lot of programs that are going to be calling posix_openpt()
> simply because /dev/ptmx can not be counted on to exist.

.. and there are probably even more programs that simply use
"/dev/ptmx". If you came from a sysv world, or if you just happened to
copy any of the hundreds of examples on the interenet, that's what you
would do.

Christ, just go to Wikipedia. And I quote:

  'BSD PTYs have been rendered obsolete by Unix98 ptys whose naming
   system does not limit the number of pseudo-terminals and access to
   which occurs without danger of race conditions. /dev/ptmx is the
   "pseudo-terminal master multiplexer". Opening it returns a file
   descriptor of a master node and causes an associated slave node
   /dev/pts/N to be created.[5]'

That's from

    https://en.wikipedia.org/wiki/Pseudoterminal

so stop blathering garbage. The fact is, /dev/ptmx is the standard
location, and /dev/pts/ptmx is, and always has been, an abomination.

Now, if you want to be portable, "posix_openpt()" is indeed what you
should use, but that doesn't change the basic point.

There's a very real reason why people use "/dev/ptmx", and no, it's
not a linuxism.

                       Linus