db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2874) NetworkServer not accepting connections with default security manager on Ipv6 machines
Date Tue, 26 Jun 2007 20:05:26 GMT

    [ https://issues.apache.org/jira/browse/DERBY-2874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508310
] 

Rick Hillegas commented on DERBY-2874:
--------------------------------------

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,

  ${derby.install.url} would be replaced with something like file:///export/home/rh161140/derby/mainline/trunk/jars/sane/
  ${derby.system.home} would be replaced with something like /export/home/rh161140/derby/mainline
  ${derby.security.host} 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).

Thanks!

> NetworkServer not accepting connections with default security manager on Ipv6 machines
> --------------------------------------------------------------------------------------
>
>                 Key: DERBY-2874
>                 URL: https://issues.apache.org/jira/browse/DERBY-2874
>             Project: Derby
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 10.3.0.0
>         Environment: Ipv6 machine with ibm jvm 15
>            Reporter: Manjula Kutty
>            Assignee: Rick Hillegas
>             Fix For: 10.3.0.0
>
>         Attachments: derby-2874-01.diff, server.policy
>
>
> While running tests on Ipv6 machines using the 10.3 jars with the default security manager,
I had the following findings/questions
> I started the server like this java org.apache.derby.drda.NetworkServerControl start
-h 2002:92a:8f7a:13:9:42:74:19
> and the server started with the following command
> Security manager installed using the Basic server security policy.
> Apache Derby Network Server - 10.3.1.0 beta - (548006) started and ready to accept connections
on port 1527 at 2007-06-25 23:44: 36.835 GMT
>  
> So I think the server is using the default security manager. Then when I tried to get
conenction though ij
>  
> got the following error message
> Access denied (java.net.SocketPermission [2002:92a:8f7a:13:9:42:73:218]:34016 accept,resolve)
> java.security.AccessControlException: Access denied (java.net.SocketPermission [2002:92a:8f7a:13:9:42:73:218]:34016
accept,resolve) 
>         at java.security.AccessController.checkPermission(AccessController.java:104)
>         at java.lang.SecurityManager.checkPermission(SecurityManager.java:547)
>         at java.lang.SecurityManager.checkAccept (SecurityManager.java:1172)
>         at java.net.ServerSocket.implAccept(ServerSocket.java:466)
>         at java.net.ServerSocket.accept(ServerSocket.java:433)
>         at org.apache.derby.impl.drda.ClientThread$1.run (Unknown Source)
>         at java.security.AccessController.doPrivileged(AccessController.java:242)
>         at org.apache.derby.impl.drda.ClientThread.run(Unknown Source)
>  
> I had the derby.properties file like this
>  
> derby.database.sqlAuthorization=true
> derby.connection.requireAuthentication=true
> derby.infolog.append=true
> derby.authentication.provider=BUILTIN
> derby.stream.error.logSeverityLevel=0
> #derby.language.logStatementText=true
> # User's Definitions
> derby.user.user2=pass2

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message