Re: [PATCH 0/1] devpts: use dynamic_dname() to generate proc name

[Eric W. Biederman]

Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes:

> On Thu, Aug 24, 2017 at 12:01 PM, Christian Brauner
> <christian.brauner@xxxxxxxxxxxxx> 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.

The ptmx node on devpts is used.

Use of that device node is way more prevalent then crazy weird cases
that required us to make /dev/ptmx perform relative lookups.  People
just set the ptmxmode= boot parameter when mounting devpts if they care.

Every use case I am aware of where people actually knew about multiple
instances of devpts used the ptmx node in the devpts filesystem.


If everyone used devtmpfs we could have fixed the permissions on the
ptmx node in devpts and made /dev/ptmx a symlink instead of a device
node.   Saving lots of complexity.

Unfortunately there were crazy weird cases out there where people
created chroots or mounted devpts multiple times during boot that
defeated every strategy except making /dev/ptmx perform a relative
lookup for devpts.

The reasons I did not fix the permissions on the ptmx deivcd node was
that given the magnitude of the change needed to get to the sensible
behavior of every mount of devpts creating a new filesystem, any
unnecessary changes were just plain scary.

Further the kind of regression that would be introduced if we changed
the permissions would be a security hole if someone has some really
weird and crazy permissions on /dev/ptmx and does not use devtmpfs.




That said I could not find a distribution being that crazy and I had a
very good sample of them.  So I expect we can fix the default permissions
on ptmx node of devpts and not have anyone notice or care.



I would encourage people who are doing new things to actually use the
ptmx node on devpts because there is less overhead and it is simpler.


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.


It might be worth fixing the default permissions on the devpts ptmx node
and updating glibc to try /dev/pts/ptmx first.  That would shave off a
few cycles in opening ptys.  If you add TIOCGPTPEER there are probably
enough cleanups and simplifications that it would be worth it just
for the code improvements.


With glibc fixed we could even dream of a day when /dev/ptmx could be
completely removed.

Eric