Hi Manjula,
During the implementation of DERBY-2196, we discussed how we should
parameterize the codebases which receive permissions. There were two
main proposals:
1) Express the codebases as ${derby.jar}, ${derbynet.jar}, etc.
or
2) Express the codebases as ${derby.install.url}derby.jar,
${derby.install.url}derbynet.jar
It was decided that the second construction was more secure. Recently,
the question again came up in the context of DERBY-3083. Again there was
strong sentiment that (2) is more secure. For this reason, the default
policy grants permissions to jar files and not to the classpath. Armed
with this explanation, let me interpret the results you are seeing:
Manjula Kutty wrote:
Hi
I have some problem while starting the network server with default
policy file. I know there was some discussion regarding the default
security manager and derbynet.jar in classpath.
Here are the scenarios I used,
1. Have only classes in the classpath : Theoretically this should
work, but I'm getting error message
$ echo $CLASSPATH
c:/workspace/trunk/classes
$ java org.apache.derby.drda.NetworkServerControl start
Cannot find derbynet.jar on the classpath.
But works if I give noSecurityManager option
$ java org.apache.derby.drda.NetworkServerControl start -noSecurityManager
Apache Derby Network Server - 10.4.0.0 <http://10.4.0.0> alpha -
(596490M) started and ready to ac
cept connections on port 1527 at 2007-11-20 23:04: 08.410 GMT
This fails because permissions must be granted to jar files. The server
cannot find derbynet.jar on the classpath--just as it says.
2. Now I gave derbynet.jar in the Classpath, but after the classes,
still getting the same error message, /see I have derbynet.jar in my
classpath/
$ export
CLASSPATH="c:/workspace/trunk/classes;c:/workspace/trunk/jars/insane/de
rbynet.jar"
$ java org.apache.derby.drda.NetworkServerControl start
Cannot find derbynet.jar on the classpath.
You have put the server code in two places on your classpath. The VM
will choose the first location when it resolves references to server
code. This means that the permissions must be granted to that first
location. However, as explained above, we only grant permissions to jar
files, not to the classpath. At server startup, we fail because we
detect that the server will not be granted its necessary permissions.
However, I can see that in this situation the error message is misleading.
It works only if I give the derbynet.jar first in the classpath
$ export
CLASSPATH="c:/workspace/trunk/jars/insane/derbynet.jar;c:/workspace/tru
nk/jars/insane/derby.jar;c:/workspace/trunk/classes"
$ java org.apache.derby.drda.NetworkServerControl start
Security manager installed using the Basic server security policy.
Apache Derby Network Server - 10.4.0.0 <http://10.4.0.0> alpha -
(577421M) started and ready to ac
cept connections on port 1527 at 2007-11-20 23:09:09.353 GMT
The server detects that permissions will be granted to the copy of the
server code which will actually be run.
3. It works with only classes in the directory if I'm using policy
file other than the default policy file
$ export CLASSPATH="c:/workspace/trunk/classes"
$ java -Djava.security.manager
-Djava.security.policy=/workspace/trunk/java/test
ing/org/apache/derbyTesting/functionTests/util/derby_tests.policy
org.apache.der
by.drda.NetworkServerControl start
2007-11-20 23:13:36.697 GMT Thread[main,5,main]
java.security.AccessControlExcep
tion: access denied (java.io.FilePermission derby.log read)
Apache Derby Network Server - 10.4.0.0 <http://10.4.0.0> alpha -
(596490M) started and ready to ac
cept connections on port 1527 at 2007-11-20 23:13:36.777 GMT
Apache Derby Network Server - 10.4.0.0 <http://10.4.0.0> alpha -
(596490M) started and ready to ac
cept connections on port 1527 at 2007-11-20 23:13:36.777 GMT
When you specify your own policy file, the server defers to your
judgment. This is, in fact, what we want users to do. We want the users
to secure their servers with policy files that are tailored to real
production environments. The server only installs its own
SecurityManager and crude policy file if the user forgets to secure the
server.
So is there a way to adjust the default policy file to accept classes?
If there is a way, do we want that in the default policy file?
If you feel passionately about this topic, feel free to join the
discussion on DERBY-3083. Note that the problems you are seeing are
artifacts of a development environment. These problems are very annoying
to Derby developers and no doubt have wasted a fair amount of your time.
However, I would not expect to see these problems in a production
environment deployed against Derby's jar files.
Hope this helps,
-Rick
Thanks,
Manjula.
