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