db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "quartz (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2451) a client can crash connections of another client
Date Thu, 05 Jul 2007 15:56:04 GMT

    [ 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:
>            Reporter: quartz
>            Priority: Critical
> Using
> 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
> 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.

View raw message