[lkml]   [1998]   [Apr]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: pty pairs in POSIX with devpts
Ulrich Drepper writes ("Re: pty pairs in POSIX with devpts"):
> (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

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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to

 \ /
  Last update: 2005-03-22 13:42    [W:0.066 / U:47.996 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site