From: ebiederm@xmission.com (Eric W. Biederman)
To: Christian Brauner <christian.brauner@canonical.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>, Serge Hallyn <serge@hallyn.com>,
        Stefan Lippers-Hollmann <s.l-h@gmx.de>,
        Christian Brauner <christian.brauner@ubuntu.com>,
        Thorsten Leemhuis <regressions@leemhuis.info>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Linus Torvalds <torvalds@linux-foundation.org>
References: <20170816171211.4021-1-christian.brauner@ubuntu.com>
        <CA+55aFz+qGxM9MidcvQkP4er-qn0_oEqCac=ob64f+twhptSgQ@mail.gmail.com>
        <CA+55aFxXzwoDdN72m2oaV4XuxO0DGoT+Bp84i07VFpLQ3Ftcpw@mail.gmail.com>
        <87pobvruzt.fsf@xmission.com>
        <CA+55aFyJsxsxeW-8RX83AM2zs+_i8h85i99X+YkuFEqpqjtp4w@mail.gmail.com>
        <87ziazqdfr.fsf@xmission.com>
        <CA+55aFwssaZpapQdc2iVVmMt0KxTHYdeo71Xbp4Ex-pYP_MpMw@mail.gmail.com>
        <20170824022436.44adb497@mir>
        <CA+55aFzHa0vL2Yui05r6aSQM0-oHuUAjqi1kxheG_tFQRkUGYw@mail.gmail.com>
        <87378hhi3y.fsf@xmission.com>
        <CA+55aFxhg8=KMZDtF-TrVjb3fPNvSWUveuRy1HHGuWXQ3+YzwQ@mail.gmail.com>
        <CA+55aFw737C9OVC2nQgGcazhi7Ca2K-frzgN2MiD=XqqFAp8YA@mail.gmail.com>
        <CA+55aFwvwtFCH2THn1LirOpMsZ57pnNi61nXQfQ6NBgakdXpTQ@mail.gmail.com>
        <87wp5tfynr.fsf@xmission.com> <20170824062432.1e05e6f8@mir>
        <874lsxezal.fsf@xmission.com>
        <CA+55aFz62HAC=v0=wVDPwdSPRXAnPGoAec1o==22AqrQchUzUQ@mail.gmail.com>
        <CA+55aFyO-70cz3ByOmD3zWByy+1x20VK5UajLa1p_-Gi8Y1nQg@mail.gmail.com>
        <CA+55aFxiDZAcFvngiNGUT=o78i1SWZ-tSHDYV4TKebiixiD6Pg@mail.gmail.com>
        <87y3q8ermg.fsf@xmission.com>
        <CAPP7u0WHqDfxTW6hmc=DsmHuoALZcrWdU-Odu=FfoTX26SGHQg@mail.gmail.com>
Date: Thu, 24 Aug 2017 14:48:47 -0500
In-Reply-To: <CAPP7u0WHqDfxTW6hmc=DsmHuoALZcrWdU-Odu=FfoTX26SGHQg@mail.gmail.com>
        (Christian Brauner's message of "Thu, 24 Aug 2017 21:01:59 +0200")
Message-ID: <87wp5sd9wg.fsf@xmission.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [PATCH 0/1] devpts: use dynamic_dname() to generate proc name
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1395
Lines: 33

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

> On Aug 24, 2017 20:41, "Eric W. Biederman" <ebiederm@xmission.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