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]
Message-ID: <CA+55aFykrX-sUpoeT-wdqhfxi=Q4q44v5025PZLG8vkETTi+Jw@mail.gmail.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ