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

Date:   Thu, 24 Aug 2017 12:22:19 -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 12:01 PM, Christian Brauner
<christian.brauner@...onical.com> wrote:
>
> I've touched on this in my original message, I wonder whether we currently
> support  mounting  devpts at a different  a location and expect an open on a
> newly created slave to work.

Yes. That is very much intended to work.

> Say I mount devpts at /mnt and to open("/mnt/ptmx", O_RDWR | O_NOCTTY) and get a new slave pty at /mnt/1 do we
> expect open("/mnt/1, O_RDWR | O_NOCTTY) to work?

Yes.

Except you actually don't want to use "/mnt/ptmx". That ptmx node
inside the pts filesystem is garbage that we never actually used,
because the permissions aren't sane. It should probably be removed,
but because somebody *might* have used it, we have left it alone.

So what you're actually *supposed* to do is

 - create a ptmx node and a pts directory in /mnt

 - mount devpts on /mnt/pts

 - use /mnt/ptmx to create new pty's, which should just look up that
pts mount directly.

And yes, the pathname should then be /mnt/pts/X for the slave side,
and /mnt/ptmx for the master.

In fact, I just tested that TIOCGPTPEER, including using your original
test-program (this is me as root in my home directory):

  [root@i7 torvalds]# mkdir dummy
  [root@i7 torvalds]# cd dummy/
  [root@i7 dummy]# mknod ptmx c 5 2
  [root@i7 dummy]# mkdir pts
  [root@i7 dummy]# mount -t devpts devpts pts
  [root@i7 dummy]# ../a.out
  I point to "/home/torvalds/dummy/pts/0"
  [root@i7 dummy]# umount pts/
  [root@i7 dummy]# cd ..
  [root@i7 torvalds]# rm -rf dummy

There's two things to note there:

 - look at that "I point to" - it's not hardcoded to /dev/pts/X

 - look at the pts number: each pts filesystem has its own private
numbers, so despite the fact that in another window I *also* have that
ptx/0:

        [torvalds@i7 linux]$ tty
        /dev/pts/0

    that new devpts instance has its *own* pts/0, which is a
completely different pty.

this is one of those big cleanups we did with the pts filesystem some time ago.

               Linus