Forum Stats

  • 3,816,303 Users
  • 2,259,168 Discussions
  • 7,893,449 Comments

Discussions

Categories

java.net.SocketPermission - socket range

Arek
Arek Member Posts: 56
edited Nov 3, 2008 9:27AM in Java and JavaScript in the Database
Hi,

We're calling an external Java class (RMI server) from Java Stored Procedure (RMI client). The RMI server listens on 1099 socket and therefore we needed to grant

dbms_java.grant_permission( 'SLAB', 'SYS:java.net.SocketPermission', 'localhost:1099', 'connect,resolve' ) - which is fine.

The problem is however a reverse "connection" established on another socket which seems to be chosen dynamically. We're receiving the following error at runtime:

"java.security.AccessControlException: the Permission (java.net.SocketPermission localhost:56675 connect,resolve) has not been granted to SLAB. The PL/SQL to grant this is dbms_java.grant_permission( 'SLAB', 'SYS:java.net.SocketPermission', '172.16.30.3
0:56675', 'connect,resolve' )
[...]"

which as far as I can tell means that this time 56675 socket has been chosen for the reverse connection. We could grant java.net.SocketPermission on this one too and it would work fine, however it may not work the next time we run the program as a different socket can be chosen.
The idea would be to either:
a) grant SocketPermission to the whole localhost - but we don't want that
b) grant SocketPermission for a single socket or (better - range of sockets) and make sure that the RMI Client and RMI server uses this single socket only (this range of sockets respectively). How can this be done?

Any ideas?

Cheers
Arek
Tagged:
· Share on TwitterShare on Facebook

Best Answer

  • MarceloF.Ochoa
    MarceloF.Ochoa Member Posts: 229
    Answer ✓
    Hi Arek:
    AFAIK is not a problem of RMI implementation.
    Typically posix socket implementation when an application is listening in a specific port number once the connection is accepted is followed by a clone() call which find a free port number above of 1024 and use it.
    So there is no chance to change this behavior :(
    Marcelo.
    · Share on TwitterShare on Facebook

Answers

  • MarceloF.Ochoa
    MarceloF.Ochoa Member Posts: 229
    Hi Arek:
    Try this:
    exec dbms_java.grant_permission( 'SLAB', 'SYS:java.net.SocketPermission', 'localhost:1024-', 'listen,resolve');
    exec dbms_java.grant_permission( 'SLAB', 'SYS:java.net.SocketPermission', 'localhost:1024-', 'accept, resolve');
    exec dbms_java.grant_permission( 'SLAB', 'SYS:java.net.SocketPermission', 'localhost:1024-', 'connect, resolve');
    exec dbms_java.grant_permission( 'LUCENE', 'SYS:java.net.SocketPermission', 'localhost:1099', 'connect,resolve' );
    these grants are working fine with my RMI server.
    Best regards, Marcelo.
    MarceloF.Ochoa
    · Share on TwitterShare on Facebook
  • MarceloF.Ochoa
    MarceloF.Ochoa Member Posts: 229
    oops replace LUCENE by SLAB in last grant.
    Marcelo.
    · Share on TwitterShare on Facebook
  • Arek
    Arek Member Posts: 56
    Thank you Marcello,
    Yes, it works, but it is more or less the same as allowing the whole localhost.

    However - if we wanted to be picky - is there a way to limit the range to 100 ports only?

    Setting permissions is the easy part:

    dbms_java.grant_permission( 'SLAB', 'SYS:java.net.SocketPermission', '172.16.30.30:1099-1199', 'connect,resolve' );
    etc

    But how can we configure the RMI server and/or the database (which should it be?) to use only ports in this range?


    Cheers
    Arek
    · Share on TwitterShare on Facebook
  • MarceloF.Ochoa
    MarceloF.Ochoa Member Posts: 229
    Answer ✓
    Hi Arek:
    AFAIK is not a problem of RMI implementation.
    Typically posix socket implementation when an application is listening in a specific port number once the connection is accepted is followed by a clone() call which find a free port number above of 1024 and use it.
    So there is no chance to change this behavior :(
    Marcelo.
    · Share on TwitterShare on Facebook
  • Arek
    Arek Member Posts: 56
    I see.
    Thanks Marcello
    · Share on TwitterShare on Facebook
This discussion has been closed.