db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject shutting down the network server with credentials
Date Thu, 04 Jan 2007 22:45:30 GMT
I would like to continue the discussion about system shutdown and 
privileges. For further context, please see DERBY-2109.

I am a bit puzzled about the interaction between engine shutdown and 
network server shutdown. I would appreciate the community's advice about:

1) What is supposed to be happening today?

2) And what behavior would we like to see in 10.3 when we control engine 
shutdown with Java Security?

Thanks for pondering the following...
-Rick
---------------

1) What is supposed to be happening today?

I'm a bit confused by the section on "Shutting down the Network Server" 
in the Admin Guide. According to that section, if you are running with 
user authentication enabled, then you are supposed to shutdown your 
databases before shutting down the network server. This is a bit 
ambiguous. What is supposed to happen if you don't shut down your 
databases before shutting down the network server? I ran the following 
experiment:

A) I brought up the network server with user authentication enabled. 
That is, I brought up the network server with this command line:

java -Dderby.connection.requireAuthentication=true \
     -Dderby.authentication.provider=BUILTIN
     -Dderby.user.\"rick\"=rickspassword \
     -Dderby.database.sqlAuthorization=true \
     -Dderby.stream.error.logSeverityLevel=0 \
     org.apache.derby.drda.NetworkServerControl start -p 824

B) Then in another shell, I verified that I needed to specify 
username/password in order to connect to the engine with the following 
engine-shutdown URL:

jdbc:derby://localhost:8246/;shutdown=true;user="rick";password=rickspassword

I then brought down the server and ran this next experiment:

C) I again brought up the network server as in (A).

D) In another shell I connected to a database, using my credentials, 
opened a ResultSet, and went to sleep holding the ResultSet open.

E) Then in another shell, I shutdown the network server like so:

java org.apache.derby.drda.NetworkServerControl shutdown -p 8246

The server complained "Connection refused : Invalid authentication." 
Nevertheless, the server VM exitted.

Finally, I ran the following experiment:

F) I again brought up the network server as in (A).

G) I again shutdown the network server as in (E).

This time there was no outstanding open connection or database and the 
server came down without complaint.

The results of these experiments puzzle me. I think it is odd that you 
need credentials to bring down the engine, but you don't need 
credentials to bring down the network server--which then brings down the 
engine as a side effect. Is this behavior expected and correct right now?


--------------------

2) What behavior would we like to see in 10.3 when we control engine 
shutdown with Java Security?

I think we need to prevent unauthorized users from bringing down the 
network server. I wonder if there is much difference between the power 
to shutdown the engine and the power to shutdown the network server? It 
makes sense to me that if you don't have the weaker power to shutdown 
the engine, then you should not have the stronger power to shutdown the 
whole server. Which of the following behaviors seems best:

i) You cannot shutdown the network server if the engine is still running 
and/or databases are still open. Instead, first you must connect with 
the engine shutdown url and good credentials as a user who has Shutdown 
privilege. Once you have brought down the engine this way, then you can 
bring down the network server.

ii) Network server shutdown needs to require credentials, which can then 
be forwarded to the server. If the user authenticates and has Shutdown 
privilege, then the server will come down regardless of whether the 
engine is up and there are open databases. If the user does not have 
Shutdown privilege, then the operation will fail.

iii) Something else?


Mime
View raw message