lkml.org 
[lkml]   [1998]   [Apr]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: pty pairs in POSIX with devpts
    Date
    Ulrich Drepper writes ("Re: pty pairs in POSIX with devpts"):
    > pw@dancer.ca.sandia.gov (Pete Wyckoff) writes:
    >
    > > I've tried using the devpts filesystem and "/dev/pts/<minor>" for opening
    > > the slave, which seems to work fine, but wonder if I should trust that
    > > it'll be common for users to have /dev/pts mounted, with the correct
    > > permissions. (It's still experimental in late 2.1 kernels.)
    >
    > Use openpty() (in libutil). It will use whatever method is available.
    > In glibc 2.1 this means, it'll use the /dev/pts method if the kernel
    > supports it.

    What does it do if both /dev/ptmx and /dev/pty?? devices exist?

    Suppose a user runs a program that allocates a pty by scanning the
    /dev/pty?? devices and chowning the corresponding slave device when it
    manages to open a pty master. The program may terminate without
    cleaning up. (Let's say the user sent it a SIGQUIT.) The master and
    slave sides of the pty are closed, so the pty can be allocated again,
    but the owner of the slave device remains as the user who started the
    program.

    Now suppose another user runs a program that allocates a pty using
    /dev/ptmx and /dev/pts/??. There's a good chance that it will get the
    pty from the program that just died. Now the pty slave is available
    twice - once to the correct user in /dev/pts, and once to somebody
    else as /dev/tty??.

    To make the device safe, you still have to use vhangup(), but now you
    have to locate the corresponding /dev/tty?? entry and chown it, even
    though you are using SysV-style pty allocation.

    IMO, it would be sensible for slave devices in /dev/pts to have a
    different major number so that the two allocation schemes were better
    separated from each other.

    Peter

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu

    \
     
     \ /
      Last update: 2005-03-22 13:42    [W:0.019 / U:64.352 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site