This is the mail archive of the libc-hacker@sourceware.cygnus.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Cleanup of pty code


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]