[
https://issues.apache.org/jira/browse/DERBY-2451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510388
]
quartz commented on DERBY-2451:
-------------------------------
I reproduce it with SQLworkbench/J, not IJ, which is sufficient to demonstrate
the server isn't resilient enough.
I totally agree that it may well be an overlook of the privileges granted to a
client connection, and sqlworkbench/j exploits the security hole inside the
database shutdown mecanism.
However, I don't know how a generic JDBC tools would know how to issue a
shutdown to derby...
In such case, the fix is strictly a missing feature/protection to implement.
The standalone server should have the option (for backward compatibility
sadly...) to accept or not a remote shutdown. But I believe it should be just
another admin role and shutdown permission pattern like many other db
manufacturers use.
It may have to do with the DBs being lazily loaded by remote connections...
However loading lazily doesn't mean the client connection has the right to
create nor shutdown a DB. The coders may have been thinking that symetry would
be a good thing here, but it's not. (Such lazily loaded DB should only shutdown
a while after there is no connections on it (typical caching to avoid excessive
disk reloading)).
> a client can crash connections of another client
> ------------------------------------------------
>
> Key: DERBY-2451
> URL: https://issues.apache.org/jira/browse/DERBY-2451
> Project: Derby
> Issue Type: Bug
> Components: Network Server
> Affects Versions: 10.2.2.0
> Reporter: quartz
> Priority: Critical
>
> Using 10.2.2.0.
> Steps to reproduce:
> 1-Start a NetworkServerControl
> 2-Start a 1st client (sqlworkbench/J), show some rows of some db, table X
> (stay connected)
> 3-Start a 2nd client (sqlworkbench/J), show some rows of some db, table X.
> 4-disconnect 2nd client
> 5-redo the 1st client query (refresh)
> You get a non architected message, sqlstate 58009, db errorcode -4499.
> In derby log, I see a shutdown of the database, and a restart.
> No matter how badly and corrupted a client connection can get, nor if the
> client connection is
> a bug in any client, such corruption should never destabilise a "server",
> certainly not other clients connections.
> It may be that the client tries to shutdown the DB; it shouldn't have such
> privilege anyway since it
> is a network "client" connection, NOT an embedded connection.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
