Christian Brauner <christian.brau...@canonical.com> writes:
> On Aug 24, 2017 20:41, "Eric W. Biederman" <ebied...@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
