lkml.org 
[lkml]   [2017]   [Aug]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH 0/1] devpts: use dynamic_dname() to generate proc name
    Linus Torvalds <torvalds@linux-foundation.org> writes:

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

    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

    \
     
     \ /
      Last update: 2017-08-24 22:44    [W:3.825 / U:0.240 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site