Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...
Java Forum / General / May 2007

Tip: Looking for answers? Try searching our database.

Java security policy file

Thread view: 
Enable EMail AlertsStart New Thread
michaelp - 04 May 2007 08:44 GMT
Hello!

i am implementing a little RMI application, and trying to use a security
manager to grant permission to classes in my codebase.

I think I understand the principles, as well as the syntax of the policy
file.

The server starts o.k. when there is no security manager.

When I plug in the following code
      if (System.getSecurityManager() == null) {
            System.setSecurityManager(new SecurityManager());
        }

I get security exceptions.

I have tried to fix those in the security policy file, but whatever I do
or do not do, the error messages (with the security manger enabled)
remains the same.

I have also tried to deliberately put faulty syntax in my security
policy, but java does not seem to react, making me suspect the security
file is ignored. Running with -verbose didnt help either.

Is there a way to dig into the error and find out what's going on?

Thanks!

Below are some extracts.

policy file (somewhat desperately overpopulated):

grant codeBase "file:/home/michaelp/rmiDB/" {
    permission java.security.AllPermission ;
};
grant codeBase "file:/home/michaelp/rmiDB/rmi/" {
    permission java.security.AllPermission ;
};
grant codeBase "file:/home/michaelp/rmiDB/server/" {
    permission java.security.AllPermission ;
};
grant codeBase
"file:/home/michaelp/rmiDB/mysql-connector-java-3.1.12-bin.jar" {
    permission java.security.AllPermission ;
};

command line:
java  -classpath .:mysql-connector-java-3.1.12-bin.jar
-Djava.security.policy=server.policy
-Djava.rmi.server.codebase=file:/home/michaelp/rmiDB/
 server.RMIServer

stack trace:
java.lang.ExceptionInInitializerError
   at java.util.TimeZone$1.run (TimeZone.java:114)
   at java.security.AccessController.doPrivileged
(AccessController.java:96)
   at java.util.TimeZone.defaultZone (TimeZone.java:100)
   at java.util.TimeZone.getDefault (TimeZone.java:1295)
   at com.mysql.jdbc.Connection.<init> (Connection.java:1433)
   at com.mysql.jdbc.NonRegisteringDriver.connect
(NonRegisteringDriver.java:266)
   at java.sql.DriverManager.getConnection (DriverManager.java:164)
   at java.sql.DriverManager.getConnection (DriverManager.java:188)
   at rmi.DB_util.doConnect (DB_util.java:45)
   at rmi.JDBC_lag_RMIImpl.<init> (JDBC_lag_RMIImpl.java:25)
   at server.RMIServer.main (RMIServer.java:30)
Caused by: java.security.AccessControlException: permission not granted
   at java.security.AccessControlContext.checkPermission
(AccessControlContext.java:122)
   at java.security.AccessController.checkPermission
(AccessController.java:76)
   at java.lang.SecurityManager.checkPermission (SecurityManager.java:337)
   at java.lang.SecurityManager.checkLink (SecurityManager.java:496)
   at java.lang.Runtime.loadLibrary (Runtime.java:171)
   at java.lang.System.loadLibrary (System.java:175)
   at java.util.VMTimeZone.<clinit> (VMTimeZone.java:55)
   at java.util.TimeZone$1.run (TimeZone.java:114)
   ...10 more
java.security.AccessControlException: permission not granted
   at java.security.AccessControlContext.checkPermission
(AccessControlContext.java:122)
   at java.security.AccessController.checkPermission
(AccessController.java:76)
   at java.lang.SecurityManager.checkPermission (SecurityManager.java:337)
   at java.lang.SecurityManager.checkLink (SecurityManager.java:496)
   at java.lang.Runtime.loadLibrary (Runtime.java:171)
   at java.lang.System.loadLibrary (System.java:175)
   at java.util.VMTimeZone.<clinit> (VMTimeZone.java:55)
   at java.util.TimeZone$1.run (TimeZone.java:114)
   at java.security.AccessController.doPrivileged
(AccessController.java:96)
   at java.util.TimeZone.defaultZone (TimeZone.java:100)
   at java.util.TimeZone.getDefault (TimeZone.java:1295)
   at com.mysql.jdbc.Connection.<init> (Connection.java:1433)
   at com.mysql.jdbc.NonRegisteringDriver.connect
(NonRegisteringDriver.java:266)
   at java.sql.DriverManager.getConnection (DriverManager.java:164)
   at java.sql.DriverManager.getConnection (DriverManager.java:188)
   at rmi.DB_util.doConnect (DB_util.java:45)
   at rmi.JDBC_lag_RMIImpl.<init> (JDBC_lag_RMIImpl.java:25)
   at server.RMIServer.main (RMIServer.java:30)
Reply to this Message
Tom Hawtin - 04 May 2007 15:50 GMT
>    at java.util.VMTimeZone.<clinit> (VMTimeZone.java:55)

A good start would be tell us what version of Java you are using.

Tom Hawtin
Reply to this Message
Michael Preminger - 04 May 2007 20:46 GMT
>>    at java.util.VMTimeZone.<clinit> (VMTimeZone.java:55)
>
> A good start would be tell us what version of Java you are using.
>
> Tom Hawtin

I use 1.6.0
Reply to this Message
Tom Hawtin - 04 May 2007 21:11 GMT
>>>    at java.util.VMTimeZone.<clinit> (VMTimeZone.java:55)
>>
>> A good start would be tell us what version of Java you are using.

> I use 1.6.0

Sun's 1.6? I can't find that source file in the source or that class
file in any JRE jar.

Are you sure you are not picking another Java runtime? For instance, the
GNU Java effort. If you add -showversion to the command line (before the
class name), it should display the exact version.

Doing a google for VMTimeZone seems to indicate that you are using the
GNU. So, I suggest specifying the full path to java in the command line
(and perhaps removing the GNU implementation).

Tom Hawtin
Reply to this Message
Lew - 05 May 2007 14:16 GMT
>>>>    at java.util.VMTimeZone.<clinit> (VMTimeZone.java:55)
>>>
[quoted text clipped - 12 lines]
> GNU. So, I suggest specifying the full path to java in the command line
> (and perhaps removing the GNU implementation).

I thought it was illegal to write classes in the java[x] packages unless you
were Sun.

Signature

Lew

Reply to this Message
Tom Hawtin - 05 May 2007 14:37 GMT
>> Doing a google for VMTimeZone seems to indicate that you are using the
>> GNU. So, I suggest specifying the full path to java in the command
>> line (and perhaps removing the GNU implementation).
>
> I thought it was illegal to write classes in the java[x] packages unless
> you were Sun.

Illegal in the sense that the specs say not to. Non-Sun JSRs can add
public classes to java[x].

Presumably VMTimeZone is a package-private class. That doesn't change
the API, so it's okay.

Tom Hawtin
Reply to this Message
Lew - 05 May 2007 18:17 GMT
>>> Doing a google for VMTimeZone seems to indicate that you are using
>>> the GNU. So, I suggest specifying the full path to java in the
>>> command line (and perhaps removing the GNU implementation).

Lew wrote:
>> I thought it was illegal to write classes in the java[x] packages
>> unless you were Sun.

> Illegal in the sense that the specs say not to. Non-Sun JSRs can add
> public classes to java[x].
>
> Presumably VMTimeZone is a package-private class. That doesn't change
> the API, so it's okay.

I thought it was literally illegal, in that it violates the trademark on "Java".

Signature

Lew

Reply to this Message
Tom Hawtin - 05 May 2007 18:24 GMT
> I thought it was literally illegal, in that it violates the trademark on
> "Java".

I am not a lawyer: I don't believe the GNU Java implementation claims to
be Java(TM). I understand that Microsoft had a contract with Sun which
did impose restrictions, and that Microsoft was found in court to have
broken some of those clauses.

Tom Hawtin
Reply to this Message
Lew - 05 May 2007 18:42 GMT
>> I thought it was literally illegal, in that it violates the trademark
>> on "Java".
[quoted text clipped - 3 lines]
> did impose restrictions, and that Microsoft was found in court to have
> broken some of those clauses.

You were right about package-private classes being permissible, as I read the
license for the Java specification from the Sun web site,
<http://java.sun.com/javase/6/docs/legal/license.html>
ss. 2 (b):

> Sun also grants you a ... license ,,,
> to create and/or distribute an Independent Implementation of the Specification
[quoted text clipped - 3 lines]
> classes, Java interfaces, fields or methods within the Licensor Name Space
> other than those required/authorized by the Specification or Specifications being implemented

If the Gnu version were not Java then we would be powerless to help in a Java
newsgroup.

Signature

Lew

Reply to this Message
Esmond Pitt - 07 May 2007 08:07 GMT
> If the Gnu version were not Java then we would be powerless to help in a
> Java newsgroup.

The Gnu 'Java' is sufficiently unlike Java that I invariably recommend
it be deleted and replaced with a Sun or IBM JRE when found, and that
invariably fixed whatever the problem is.
Reply to this Message
Matej Cepl - 07 May 2007 08:49 GMT
> The Gnu 'Java' is sufficiently unlike Java that I invariably
> recommend it be deleted and replaced with a Sun or IBM JRE when
> found, and that invariably fixed whatever the problem is.

Does this announcement from gcc.gnu.org/java changes something in
your opinion?

   January 8, 2007
       We've merged the gcj-eclipse branch to svn trunk. The
   merge changes gcj to use the Eclipse compiler as a front end,
   enabling all 1.5 language features. This merge also brings in
   a new, generics-enabled version of Classpath, including some
   new tools.  This new code will appear in GCC 4.3.

Matej
Reply to this Message
Lew - 07 May 2007 12:52 GMT
Esmond Pitt wrote:
>> The Gnu 'Java' is sufficiently unlike Java that I invariably
>> recommend it be deleted and replaced with a Sun or IBM JRE when
>> found, and that invariably fixed whatever the problem is.

> Does this announcement from gcc.gnu.org/java changes something in
> your opinion?
[quoted text clipped - 5 lines]
>     a new, generics-enabled version of Classpath, including some
>     new tools.  This new code will appear in GCC 4.3.

No.

Signature

Lew

Reply to this Message
Mark Thornton - 07 May 2007 14:33 GMT
>> The Gnu 'Java' is sufficiently unlike Java that I invariably
>> recommend it be deleted and replaced with a Sun or IBM JRE when
[quoted text clipped - 11 lines]
>
> Matej

It will be a while before that is the version commonly found. For
example an up to date copy of Suse 10.2 has ClassPath 0.92. Many
installations will have even older versions, and those older versions
are the ones on which the impression of 'not working' is based.
It is only in the past 6 months or so that there has been any chance of
my own code working on ClassPath (although as my latest work targets 1.6
that is probably won't work either).

Mark Thornton
Reply to this Message
Esmond Pitt - 08 May 2007 01:38 GMT
> Does this announcement from gcc.gnu.org/java changes something in
> your opinion?

No. If it is now compatible with Sun Java it will be self-incompatible,
and in either case it can't be of any practical use.
Reply to this Message
Arne Vajhøj - 09 May 2007 01:59 GMT
>> The Gnu 'Java' is sufficiently unlike Java that I invariably
>> recommend it be deleted and replaced with a Sun or IBM JRE when
[quoted text clipped - 9 lines]
>     a new, generics-enabled version of Classpath, including some
>     new tools.  This new code will appear in GCC 4.3.

Will it be certified ?

Arne
Reply to this Message


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage
Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.