[
https://issues.apache.org/jira/browse/DERBY-3532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12735112#action_12735112
]
Kathey Marsden commented on DERBY-3532:
---------------------------------------
Lily said:
I am not sure what Derby can do at this case. It will be nice if
derbynet.ServerPropertiesTest and management.InactiveManagementMBeanTest does
not try to shutdown network server with embedded data source.
It is a little confusing with the different shutdowns going on.
The tests are not shutting down network srever with the embedded driver but
rather using it to shutdown the embedded engine which network server is using.
So when we reproduce the bug the sequence is in a single JVM:
1) start network server
2) shutdown the embedded engine (not network server) with the embedded driver
(either DriverManager.getConnection("jdbc:derby:;shutdown=true) or with
EmbeddedDataSource as the latest repro.
3) Shutdown network server. Since network server relies on the embedded engine
to manage authentication and it is now gone the findService() call is null.
I am sure also there are other network server cleanup issues in this scenario.
In our first attempt at ReproDerby3532 in step 2 we shutdown the embedded
engine with the client driver. In this case Network Server is aware that the
engine is being shutdown because it came in through the client. Network Server
catches the XJ015 error cleans up some of the network server threads and
sessions and threads and restarts the embedded engine.
This happens in DRDAConnThread.writeSQLCARD(). The cleanup and engine restart
occurs in the poorly named NetworkServerControl.startNetworkServer() which
cleans up network server if needed and starts the embedded engine.
One option is to document that users should not shutdown the embedded engine
with the embedded driver while network server is running and as you suggest,
change here
change the tests to shut down the engine with the client driver.
I wonder instead if it would work and be worth it to put a lightweight check in
network server for each client request to see if the embedded engine is
running and if it is not, do the cleanup and start the embedded engine. Then
we would always find the authentication service on shutdown and would be able
to handle any other cleanup issues as well.
Thoughts?
> Invalid & possibly skipped authentication handling when shutting down the
> network server.
> ------------------------------------------------------------------------------------------
>
> Key: DERBY-3532
> URL: https://issues.apache.org/jira/browse/DERBY-3532
> Project: Derby
> Issue Type: Bug
> Components: Network Server
> Affects Versions: 10.4.1.3, 10.5.1.1
> Reporter: Daniel John Debrunner
> Priority: Critical
> Attachments: ReproDerby3532.java, ReproDerby3532.java
>
>
> In NetworkServerControlImpl.checkShutdownPrivileges() code fetches the
> internal authentication service to perform user authentication.
> However if no such authentication service is found (null is returned) then
> authentication is bypassed, this has the potential of being a security hole.
> The discussion in DERBY-2109 indicated that even with authentication NONE,
> there is still an internal authentication service, thus null is not a valid
> return when getting the internal authentication service. A secure fail safe
> system would be to not bypass authentication if null is returned.
> I tried removing the check for null in the method and that lead to
> NullPointerExceptions. This means that something wrong is going on and very
> possibly no authentication checks are actually being made when shutting down
> the network server.
> The null return might be due to checking the authentication after Derby has
> been shutdown.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
