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 18:01:36 -0500
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     Linus Torvalds <torvalds@...ux-foundation.org>
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

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.

> 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.

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.

> So pretty much every single user that ever uses pty's will use
> /dev/ptmx, it's just how it has always worked.
>
> Trying to change it to anything else is just stupid. There's no
> upside, there is only downsides - mainly the "we'll have to support
> the standard way anyway, that newfangled way doesn't add anything".

Except the new fangled way does add quite a bit.  Not everyone who
mounts devpts has permission to call mknod.  So /dev/ptmx frequently
winds up either being a bind mount or a symlink to /dev/pts/ptmx in
containers.

It is going to take a long time but device nodes like one of those
filesystem features thare are very slowly on their way out.

> Our "pts" lookup isn't expensive.
>
> So quite frankly, we should discourage people from using the
> non-standard place. It really has no real advantages, and it's simply
> not worth it.

The "pts" lookup admitted isn't runtime expensive.  I could propbably
measure a cost but anyone who is creating ptys fast enough to care
likely has other issues.

The "pts" lookup does have some real maintenance costs as it takes
someone with a pretty deep understanding of things to figure out what is
going on.  I hope things have finally been abstracted well enough, and
the code is used heavily enough we don't have to worry about a
regression there.   I still worry.

As for non-standard locations.  Anything that isn't /dev/ptmx and
/dev/pts/NNN simply won't work for anything isn't very specialized.
At which point I don't think there is any reason to skip using the ptmx
node on the devpts filesystem as you have already given up compatibility
with everything else.

But I agree it doesn't look worth it to change glibc to deal with an
alternate location for /dev/ptmx.  I see a huge point in changing glibc
to use the new TIOCGPTPEER ioctl when available as that is really the
functionality the glibc internals are after.

Eric