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

Date:   Thu, 24 Aug 2017 14:48:47 -0500
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     Christian Brauner <christian.brauner@...onical.com>
Cc:     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>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH 0/1] devpts: use dynamic_dname() to generate proc name

Christian Brauner <christian.brauner@...onical.com> writes:

> On Aug 24, 2017 20:41, "Eric W. Biederman" <ebiederm@...ssion.com> wrote:
>
> > The implementation of TIOCGPTPEER has two issues.
> >
> > When /dev/ptmx (as opposed to 
>
> 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. 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.

In particular one of my crazy test cases when I did the last round
of cleanups to devpts was someone had created a chroot including
a /dev/ptmx device node and mounted devpts at the appropriate path
inside the chroot.  Which is in part why /dev/ptmx does a relative
lookup of the devpts filesystem.

Now glibc won't work with devpts mounted somewhere else.  As it has
/dev/pts/... hardcoded.  But the kernel should work fine.  The case you
described using /mnt/ptmx instead of a random /dev/ptmx device now
should work especially well as none of this crazy relative path lookup
work needs to happen.

There are little things such as TIOCSPTLCK and perhaps chmod that need
to be called in your example before the slave open will succeed (without
O_PATH) but yes that case most definitely should work.

Eric