Thanks for running this experiment, Manjula. I'm a little unclear on what test you tried. The command line above indicates that you installed your own security manager and used your own policy file. The policy file you used has unsubstutited parameters in it. It doesn't appear as though any of those parameters are declared on your command line, so the VM won't substitute them. That would explain why you have now lost file permissions as well as the socket permission. Those parameters are forced to reasonable values by the server only if the server decides that it needs to install its own security manager and default policy file.
Could you try the following experiments:
1) In your server policy file, replace the parameters with good values. So for instance,
would be replaced with something like file:///export/home/rh161140/derby/mainline/trunk/jars/sane/
would be replaced with something like /export/home/rh161140/derby/mainline
would be replaced with the host address you use as the -h argument on your command line
Since you are running with your own policy file you will probably also need to add the following permission to the rights granted to derby.jar:
permission java.util.PropertyPermission "user.dir", "read";
2) In the second experiment, it would be great if you could apply the patch to your workspace and build the jar files. Then use those jar files to run the original test which you described in your first mail message--that is, just bring boot the server with your port specification but without declaring a security manager or policy file. This should force the server to install its own security manager and pick up the new default policy file (which is the only change introduced by the patch).