On 06/10/2014 07:01 AM, One Thousand Gnomes wrote:
This patch only affects the line state if the last tty reference is closed
or the tty is hung up by software (like on controlling process exit).
In this case, any login session is already dying, and it would not be possible
to hijack a live session. A successful re-login is still required.
It breaks the other direction - yes sorry.
Notwithstanding what I wrote above, this patch does change behavior
with remote consoles, which may be unacceptable.
For example, if the remote user logs out, the current behavior hangs up
the modem (if HUPCL), whereas the patch behavior just presents a new
login prompt.
which means the modem will probably no longer answer calls.
I would expect the vast majority of modems to be configured to hang-up
after carrier loss (when the remote user hangs up).
I think the more significant impact is that killing the login process
(by the sysadmin) wouldn't disconnect a malicious user (but would still
force the re-login). I see this as more nuisance value than any
realistic DoS.
So yeah, I agree; this patch should be dropped.
Possibly we should also fix this the other way in tty_port_shutdown,
which does wrongly skip dtr/rts handling of consoles.
As far as I can see providing HUPCL is clear the desired console
behaviour for most situations with a remote console link is obtained.
I agree that serial core and tty port should handle the console
identically, so if the serial core defaults are the expected behavior,
then, yes, tty_port_shutdown() should not skip dropping dtr/rts.
However, a console on USB tty is much more likely to be local, rather
than remote, so changing dtr/rts handling could impact these setups.
Since the termios c_cflag is inherited from the console, what about adding
new flow control flag decodes to uart_set_options(); eg.,
'r' = CRTSCTS | HUPCL /* existing */
'R' = CRTSCTS | !HUPCL
default = !CRTSCTS | HUPCL
'd' = !CRTSCTS | !HUPCL
?
Regards,
Peter Hurley
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
