This is the mail archive of the
libc-hacker@sourceware.cygnus.com
mailing list for the glibc project.
Re: Cleanup of pty code
- To: zack@rabi.columbia.edu
- Subject: Re: Cleanup of pty code
- From: Mark Kettenis <kettenis@phys.uva.nl>
- Date: Fri, 18 Sep 1998 09:48:49 +0200 (MET DST)
- CC: hpa@transmeta.com, libc-hacker@cygnus.com
- References: <199809180047.UAA15842@rabi.phys.columbia.edu>
Hi Zack,
Date: Thu, 17 Sep 1998 20:47:31 -0400
From: Zack Weinberg <zack@rabi.columbia.edu>
The patch looks good to me by eye, but I haven't tried it. One thing: I
think checking whether the pty has been set up right by looking for the
`devpts' filesystem is a bit shaky. devfs sets up the pty automatically
too, and other implementations might do the same. What was wrong with
checking the output of stat()?
The old code did only check if the user was already set to the uid of
the program. If they matched, it left the group and access
permissions alone. However, because most applications do not reset
the pty permissions when they are finished, it is possible that the
user is already set to the right uid, but that the group and access
permissions contain garbadge. That's why I added code to the generic
unix `grantpt' function to check the group and the access permissions
too.
The reason to handle `devpts' special, is that the kernel allows the
`devpts' filesystem to be mounted with the group and access
permissions set differently from what `grantpt' wants them to be. I
assumed that if this is the case, the system administrator knows what
he is doing and doesn't want `grantpt' to set them to `tty' and
`620'.
I don't exactly know what `devfs' does. It's not in the standard
kernel. But supporting `devfs' should be easy. Just check against
the `devfs' filesystem identifier too.
Mark