Re: Bug in serial line hangup code ?
Peter Fox (fox@roestock.demon.co.uk)
Wed, 8 May 96 07:47 BST
> Date: Tue, 7 May 1996 12:47:10 -0400
> From: Theodore Ts'o <tytso@MIT.EDU>
>
> Date: Tue, 7 May 96 07:44 BST
> From: Peter Fox <fox@roestock.demon.co.uk>
>
> Obviously, it is meaningless for two processes to have the same port
> open for I/O, which is why there are lockfiles etc, but
> I've certainly found the ability to monitor the port useful, so if there
> is a way to let a process do ioctls etc, immune from hangups etc, then
> please do revisit the hangup code.
>
> Once a hangup occurs, the process doesn't have the port open for I/O.
> That's the way it is for security reasons. What would be useful for
> your port monitoring program will also be useful to an attacker who
> wishes to run a port monitoring program....
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.
If someone has a paranoiac program that wants to use the line, it can
always read the info.count using TIOCSERGSTRUCT and refuse to use the
line if another process has it open.
Peter