Messages in this thread |  | | Date | Wed, 8 May 1996 15:09:25 -0400 | From | "Theodore Y. Ts'o" <> | Subject | Re: Bug in serial line hangup code ? |
| |
Date: Wed, 8 May 96 07:47 BST From: Peter Fox <fox@roestock.demon.co.uk>
But that's what I don't want. After hangup, if I catch SIGHUP, I want to keep the port open so I can do ioctls on it.
I fail to see how it is any more of a security risk than a monitor program simply reopening the port. Even though the patches allow the monitor program to do ioctls on the hung up port, it doesn't allow any data access while the port is hungup.
That's assuming that the program still has privileges to reopen the port. getty is supposed chown the port and then call vhangup() to force off any users....
You can do an awful lot of damange using ioctl()'s. You can force characters to appear on the tty as if the user had typed them, etc. etc.
The basic paradigm of a hangup is that *all* open file descriptors get forced off (the POSIX standard uses the language of "revoking access"), and from the point of the kernel, it's as if no one has the port open any more. That's why rs_hangup() forcibly shuts down the UART at this point; those file descriptors don't matter when considering whether or not the serial port is open.
You want to fundamentually break this paradigm for the convenience of your port monitoring program, and I'm still not convinced that (a) it's worth the effort, and I _know_ that (b) doing so will disrupt a lot of assumptions made by both kernel programs and user-mode getty and login programs.
- Ted
|  |