[
https://issues.apache.org/jira/browse/DERBY-7107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17304904#comment-17304904
]
Holger Rehn edited comment on DERBY-7107 at 3/20/21, 7:54 PM:
--------------------------------------------------------------
[~rhillegas]
??but I don't know how to guarantee that it won't break existing applications??
The only problems I can think of are the following corner cases:
# The server is started on INADDR_ANY and currently can be connected using
that address. The system has a localhost address that is chosen by the patch
but that cannot be connected for any strange reason.
# The NetworkServerControl is created using a specifiv IP version of
INADDR_ANY (address is the same, but different InetAddress implementations) and
- for any reason I cannot even imagine - can only be connected using that
specific InetAddress version.
The 1st cenario could theoretically be found if a firewall explicitly blocks
the localhost address but doesn't block INADDR_ANY. I'm not sure we want to
really implement a workaround for that. In any sane environment this shouldn't
happen and as I said, INADDR_ANY isn't even a valid target address, at all. For
the 2nd scenario I cannot even make up anything...
??start NetworkServerControl with whatever address is the result of the
computation performed by the patch???
This definitly breaks existing applications. One of the most common reasons to
start NetworkServerControl on INADDR_ANY may be to allow external access to an
integrated DB instance. By starting it on a localhost address only local
connections would be allowed.
was (Author: ickzon):
[~rhillegas]
??but I don't know how to guarantee that it won't break existing applications??
The only problems I can think of are the following corner cases:
# The server is started on INADDR_ANY and currently can be connected using
that address. The system has a localhost address that is chosen by the patch
but that cannot be connected for any strange reason.
# The NetworkServerControl is created using a specifiv IP version of
INADDR_ANY (address is the same, but different InetAddress implementations) and
- for any reason I cannot even imagine - can only be connected using that
specific InetAddress version.
The 1st cenario could theoretically be found if a firewall explicitly blocks
the localhost address but doesn't block INADDR_ANY. I'm not sure we want to
really implement a workaround for that. In any sane environment this cannot
happen and as I said, INADDR_ANY isn't even a valid target address, at all. For
the 2nd scenario I cannot even make up anything...
??start NetworkServerControl with whatever address is the result of the
computation performed by the patch???
This definitly breaks existing applications. One of the most common reasons to
start NetworkServerControl on INADDR_ANY may be to allow external access to an
integrated DB instance. By starting it on a localhost address only local
connections would be allowed.
> NetworkServerControl fails to connect to server started on INADDR_ANY
> ---------------------------------------------------------------------
>
> Key: DERBY-7107
> URL: https://issues.apache.org/jira/browse/DERBY-7107
> Project: Derby
> Issue Type: Bug
> Components: Network Server
> Affects Versions: 10.14.2.0, 10.15.2.0
> Reporter: Holger Rehn
> Priority: Critical
> Attachments: DERBY-7107.diff
>
>
> If starting a NetworkServerControl on INADDR_ANY (0.0.0.0) it also uses this
> address when connecting to the running server instance (e.g. in method
> ping(), ...).
> Strictly speaking, INADDR_ANY isn't a valid target address. However, under
> normal circumstances, this works anyway. But if you have any "security"
> software in place that blocks such connections (Firewall or VPN, e.g. Cisco
> AnyConnect), you end up with an IOException:
> {code}Could not connect to Derby Network Server on host 0.0.0.0, port 1527:
> Permission denied: connect.{code}
> One simple fix would be to explicitly check the host address 'hostAddress' in
> NetworkServerControlImpl.setUpSocket() and if this is INADDR_ANY, use
> 'localhost' instead.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
