.java.policy file problem

Is there someone who knows how to reinitialise the java policy file at runtime?
My signed applet writes a policy file to the users home directory, but that file is only used after closing the browser and surfing back to our page. It should immediatly use that new file.
Someone who got some experience with that...?
Regards

And is it true that if you use a Thawte or verisign certificate, you will not have to change the .java.policy file?

Similar Messages

Can distribution of a .java.policy file be eliminated

Sorry for the stupid question, but I'm fairly new to the realm of dealing with Java security...
I have an applet that I want to deploy worldwide as part of an upgrade to an existing website, but I've run into the following error:
"Error getting connection to: jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.0.101)(PORT=1521)))(CONNECT_DATA=(SID=EKB)(SERVER=DEDICATED))) using oracle.jdbc.driver.OracleDriver
access denied (java.util.PropertyPermission oracle.jserver.version read)"
I have managed to figure out that I can eliminate this problem by placing a .java.policy file on all client machines that contain the following:
"grant {
permission java.util.PropertyPermission "oracle.jserver.version", "read";
However, is there any way to eliminate the need to distribute the policy file to those wanting to use the web site's applet? Can it be done somehow within the SSL certificate that I seemingly also have to distribute?
Any help for this newbee would be appreciated!

In contrast to what many people say in this forum, it is possible to have an unsigned applet access a database. You don't even have to manipulate the client's policy-file. The requirement is that the database is located on the same machine as the applet is downloaded from.There are however other things that can break this possibility. One is the database-driver itself.
In the case of Oracle we have tried using different versions of the driver. When using version 8.1.7 or 9.0.1 things work nicely, but when switching to version 9.2 it stops working. There is a question on OTN [1]. Let's see what Oracle has to say about it.
[1] Problem connecting using Oracle JDBC drivers

Essential question concerning java.policy file

I have been searching this forum for an answer to this question:
Is there a way to run a signed applet on an intranet (via the Plugin) with out having to go around to each user's workstation and change their java.policy file?
So far, I have seen this question asked several times but with no concrete answer.
Thanks for any help!

You can create your own Policy implementation as shown in the following link :
http://www.javageeks.com/Papers/JavaPolicy/index.html
This has some drawbacks.
I overcame your problem by writing my own Security Manager.

How to handle the java.policy file ?

Can somebody tell me how to handle the java.policy file?
I always get java.net.SocketExceptions and java.security.AccessControlExceptions while connecting to an appserver from an applet.
What do I have to write in the java.policy file, where do I have to place it and do I have to call it in some way form my applet?
Thanks in advance.
don call

The java.policy file goes in your jre installation directory in .../jre/lib/security (there should be one there already).
I used it to allow otherwise restricted permissions for an applet using javax.comm. Add something like the following to the file:
grant codeBase "URL:http://yourDomainName/rootDirectoryOfYourApp/*" {
permission java.security.AllPermission;
This will give the applet downloaded from your site all permissions. You might want to give only certain permissions, I don't know.
Teri

File Access with unsigned Applet through editing the java.policy file

I'am starting to lose my hair on this...
I am trying to get an applet to run so that it can access the file system to move files on my local maschin. Because this applet is only running on my VM i can change the java.policy to avoid the signing of the applet.
first of all, if i wrote in the java.policy file
grant {
permission java.security.AllPermission;
};everything is working perfekt.
But I have not the intention to open the gates for any applet out there, so i want to limit the access to my applet. With every of the following versions I get at best an
java.security.AccessControlException: access denied (java.io.FilePermission...
My Setup
My Java Version: jre1.6.0_02
My applet is located unter the url
http://admin.mydomain.com/applet.jar
In Html i tryed the following different versions of loading the applet - none worked
<applet codebase="http://admin.mydomain.com/" name="shortcut" code="start.class" archive="applet.jar" width="0" height="0"></applet>
<applet codebase="http://admin.mydomain.com" name="shortcut" code="start.class" archive="applet.jar" width="0" height="0"></applet>
<applet name="shortcut" code="start.class" archive="http://admin.mydomain.com/applet.jar" width="0" height="0"></applet>in java.policy i tryed following versions with every html applet load version
grant codeBase "http://admin.x-press.de/-" {
permission java.security.AllPermission;
grant codeBase "http://admin.x-press.de/+" {
permission java.security.AllPermission;
grant codeBase "http://admin.x-press.de/applet.jar" {
permission java.security.AllPermission;
};why is it with
grant {
permission java.security.AllPermission;
};working, and not with the other versions?
i am almost bold now, please try to save my last hair from falling down.
any suggestion would be nice
thanks, feyyaz
Message was edited by:
feyyazdogu

I read the mentioned documentation and your right, some of my versions were wrong, but after reading the doumentation again i came to following result which should had worked but didn't.
java.policy
grant codeBase "http://admin.mydomain.com/*" {
permission java.security.AllPermission;
HTML File
<applet codebase="http://admin.mydomain.com/" name="shortcut" code="start.class" archive="applet.jar" height="0" width="0"></applet>if I am entering http://admin.mydomain.com/applet.jar i can download the jar, so the archive lays in the correct directory.
what i am doing wrong? do i have to change an additional file somewhere else?

".java.policy" file where is this located

Hi,
Where is the .java.policy file located. Do I have to create it? Do I have to use any editor for this? Please help me.
Thank you,
Regards
Uma

It'll probably be in the lib/security directory of your JRE.
If you've got a JDK then it'll be something like jdk1.3/jre/lib/security/java.policy

Java.policy file - Must I change it?

I just got a certificate from Verisign with which I signed my applet. It works fine and now I want to distribute it to a group of users.
Back when I was developing the applet with a self-signed cert, I changed the java.policy file to allow the applet to do things 'outside the sandbox'.
I thought, perhaps mistakenly, that when I got the Verisign ceritifcate I would not need to concern myself with java.policy in any way. But now, even with the Verisign cert, my applet won't run correctly w/o the updated policy file.
This is only important to me as I do not want to go around to 'x' number of user workstations and modify each java.policy file.
Am I missing something??
thanks

You mention
"you should be able to remove the policy file and users can just accept the certificate "
I experience the same, remove all policy files, signed applets can then access resopurces on the local machine. However, practically all the documentation I read regarding JAVA 2 (I'm using 1.4.1_02) says you must have a policy file when using a signed applet. At least they say sign your applet and then indicate what the policy file should look like to grant specific permissions for that applet. I find no policy file will still allow a signed applet to access local files... Is this a bug in JAVA 2 1.4.1_02, or the correct behavior. thanks in advance.

Where to put java.policy file?

Under which directory the "java.policy" file must be kept in?

Hi!
The policy file must be indicated in the command line or by system property, when you starts the service, like the following: -Djava.security.policy = yourfile.policy. If you want to indicate another directory, you can do like this: -Djava.security.policy = C:\temp\yourfile.policy.
I hope it helps you,
Sandra.

Granting different permissions to different codebases : policy file problem

Hi all. I'm having a bit of a problem with policy files and granting different persmissions to different codebases. What I have at the moment is a server app that copies a class file from the client to a specified directory on the server, and then dynamically loads and runs that class. This all works fine, but obviously as user submitted code is going to be run on the server I want to restrict what they are allowed to do. My app is going to be bundled up in a single jar file, and the directory that the client code is being copied to a subdirectory of the app installtion (not that this should make much difference). What i want to do is grant all permissions to my code in the jar file and resrict the permssions granted to code in the strategies directory. I assumed i would just be able to do this using my own policy file, but at the moment i'm not having much luck.
Directory structure:
c:/project/code/
|
|-labyrinth.jar
|-strategies/
Contents of labyrinth.policy:
grant codeBase "file:../code/labyrinth.jar" {
permission java.security.AllPermission;
Command line arguments:
java -Djava.security.manager -Djava.security.policy==./labyrinth.policy -classpath .;./labyrinth.jar;./strategies/;%CLASSPATH%; labyrinth.LabyrinthServer
I've tried specifiying the absolute path to the jar file in the policy file as well as the relative path, i've tried including -Xbootclasspath/a and appending the jar file. All I seem to be able to manage though is either granting all permissions system wide, including the strategies dir, or none and getting security exceptions within my code. Anyone tried doing anything similair or got any idea where I might be going wrong? Any help would be appreciated as its really starting to doing my head in.
TIA. Matt.

Did you try putting a slash at the beginning of your "file" specification? e.g., instead of saying
grant codeBase "file:../code/labyrinth.jar" {
permission java.security.AllPermission;
say
grant codeBase "file:/../code/labyrinth.jar" {
permission java.security.AllPermission;
Hope this helps.

Problems with $HOME/.java.policy

hi,
i'm using suse linux 7.3 & jdk 1.4.
i have a simple test applet that prints the user name. i signed it by:
cprokt@linux:~/java/applets/uname> jarsigner -signedjar strapp.jar trapp.jar cprokt
Enter Passphrase for keystore: dubel07
cprokt@linux:~/java/applets/uname> jarsigner -verify strapp.jar
jar verified.then i created the java policy file /home/cprokt/.java.policy
keystore "/home/cprokt/.keystore";
grant SignedBy "cprokt"
permission java.util.PropertyPermission "user.name", "read";
};Running this applet with appletviewer resulted in a AccessControlException which said:
java.security.AccessControlException: access denied (java.util.PropertyPermission user.name read)I got the same result when I ran the applet with Konqueror (blackdown vm 1.3).

It's not neccessary to have a .java.policy file if you sign the applet. I run my applets (intranet only) with a policy file alone, without signing them. The only drawback to the policy file security is that it will have to be deployed to your users, this does not work in the internet, who's going to accept your policy file, but it's not so bad in an intranet. If you sign the applet succesfully, by default you'll get "all permissions" and getting the user name should not be a problem.
Hope this helps...

Explicitly installin java.policy problem

is there any one who knows how to explicitly install the java.policy. What i have been doing is set the policy of the RMI server through a file like java.policy which contains this
grant {
permission java.security.AllPermission
"*:1024-65535","connect,accept,resolve";
and run the server through a batch file where the java.policy file is loaded through the system. is there anyone who knows to load the policy in the server code itself, that is, installing it explicitly?
thanks..

Yes, this is true ...but there is a saying about hardcode ...it makes things hard to code. Hardcoding the policy file eliminates flexibility for your clients and makes things harder to deploy. It certainly breaks from the standard. I just wouldn't want the poster to think one way is just as good as the other. But you do have a choice, this is true.

Java Networking and policy file

Two part question,
First I writing a applet that is working with sockets, I've compared this and a delphi program and it seems that the delphi program is writing to and recieving from the socket at a faster rate (four second delay for the applet) then the applet. There is no extra code besides opening the client socket and writing and receiving data.
Second question is is there a way to allow an applet to write to a socket below 1024 without having a java.policy file. If I do need the policy file is there a way to change it from the applet, or to set an work around permission. I'm writing an applet to work with a protocal that generally lives on a socket below 1024.
Thanks in advance

There is a way to let an applet access the lower sockets, but you need to sign it. And in order to sign it you need a key from verisign or Thawte. In fact, there are 2 different keys you need, one for Netscape and one for MS. But the netscape one might be the only one that you need.
Other then signing it, you have to edit your browser preferences to let applets have full access to your system. sorry :(

Server.policy file

The ejb I am developing is trying to delete the following file from a local filesystem (Linux SuSE 9.3 Pro) : /path/to/file/delete.me I get the following exception:
java.security.AccessControlException: access denied (java.io.FilePermission /path/to/file/delete.me delete)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)
at java.security.AccessController.checkPermission(AccessController.java:427)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at java.lang.SecurityManager.checkDelete(SecurityManager.java:990)
at java.io.File.delete(File.java:869)
I tried to modify the server.policy file adding the following line:
permission java.io.FilePermission "/path/to/file/delete.me", "delete";
but nothing changes, even when I restart the application server (don't know even if it is necessary to restart). I am using Sun Java System Application Server Enterprise Edition 8.1. Any help is welcome...
Thanks in advance
null

I think I solved the problem. At least I managed to delete the file :-)
First I had to add the following line to JRE's java.policy file:
permission java.io.FilePermission "/path/to/file/delete.me", "delete";Then I added the following entry to the server's server.policy file:
grant codeBase "file:${com.sun.aas.instanceRoot}/applications/j2ee-apps/MyApp-" {
permission java.io.FilePermission "/path/to/file/delete.me", "delete";
};like described here:
http://docs.sun.com/app/docs/doc/819-3659/6n5s6m58n?a=view#beabz
I hope this could help to someone with the same problem

ClassLoader & java.policy

Hi ,
I am facing problem with the following code.
ClassLoader loaderPrev = Thread.currentThread().getContextClassLoader();
ClassLoader loader = URLClassLoader.newInstance(new URL[]{new URL(CodeBase)} , loaderPrev );
ClassLoader loader = new URLClassLoader(urlList);
Thread.currentThread().setContextClassLoader(loader) ;
result = Thread.currentThread().getContextClassLoader().loadClass(className);
This loads class successfully if I give "AllPermision" in my java.policy. But in real project I cann't do this. If I give only the http port in the java.policy file, it doesn't work . It gives socket permission denied exception.
I appreciate if somebody can give some input on this.
Thanks
Surendra

try to sign applets
please check documents
or search in the forums
http://java.sun.com/security/signExample12/
http://java.sun.com/j2se/1.4/docs/guide/plugin/developer_guide/rsa_signing.html
renjith.

Java Applets and .java.policy

Hi.
We are developing an applet that need to access to the file systems and anothers properties, like user.home. To do this and don't modify the java.policy of the jre, we create a .java.policy file into user home. The content is:
grant {
permission java.util.PropertyPermission "user.name", "read";
permission java.util.PropertyPermission "user.home", "read, write";
permission java.util.PropertyPermission "java.library.path", "read, write";
permission java.lang.RuntimePermission "accessClassInPackage.org.mozilla.jss.*";
permission java.io.FilePermission "${user.home}/", "read";
permission java.io.FilePermission "${user.home}/-", "read, write";
With this configuration it works fine in Linux with Iceweasel, but in windows it's not work (firefox nor internet explorer)!.
The error is:
[SignApplet]: M�dulo iniciado.
[SignApplet]: Cliente de firma iniciado.
[ESignatureFormatFactory]: Buscando formato 'CMS'... encontrado!
[SignManager]: Firmando digitalmente...
java.lang.NullPointerException
     at java.util.Properties$LineReader.readLine(Unknown Source)
     at java.util.Properties.load(Unknown Source)
     at com.telventi.afirma.cliente.utilidades.MimeTypeHelper.<init>(MimeTypeHelper.java:23)
     at com.telventi.afirma.cliente.utilidades.MimeTypeHelper.getInstance(MimeTypeHelper.java:32)
     at com.telventi.afirma.cliente.actions.ACommonAction.<clinit>(ACommonAction.java:59)
     at com.telventi.afirma.cliente.signatureformat.signaturemanager.ASignManager.warn(ASignManager.java:405)
     at com.telventi.afirma.cliente.signatureformat.signaturemanager.SignManagerMSIEWin32.signDigitally(SignManagerMSIEWin32.java:63)
     at com.telventi.afirma.cliente.signatureformat.CMSSignatureFormat.createSignedInfo(CMSSignatureFormat.java:1562)
     at com.telventi.afirma.cliente.signatureformat.CMSSignatureFormat.signExplicitHash(CMSSignatureFormat.java:265)
     at com.telventi.afirma.cliente.signatureformat.signaturemanager.ASignManager.signHashElectronically(ASignManager.java:139)
     at com.tsol.afirma5.util.impl.AppletServiceImpl.generarFirma(AppletServiceImpl.java:60)
     at com.tsol.validacionCertificado.applet.TSolApplet.obtenerFirmaGenerada(TSolApplet.java:105)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
     at java.lang.reflect.Method.invoke(Unknown Source)
     at sun.plugin.javascript.invoke.JSInvoke.invoke(Unknown Source)
     at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
     at java.lang.reflect.Method.invoke(Unknown Source)
     at sun.plugin.javascript.JSClassLoader.invoke(Unknown Source)
     at sun.plugin.com.MethodDispatcher.invoke(Unknown Source)
     at sun.plugin.com.DispatchImpl.invokeImpl(Unknown Source)
     at sun.plugin.com.DispatchImpl$1.run(Unknown Source)
     at java.security.AccessController.doPrivileged(Native Method)
     at sun.plugin.com.DispatchImpl.invoke(Unknown Source)
java.lang.ExceptionInInitializerError
     at com.telventi.afirma.cliente.signatureformat.signaturemanager.ASignManager.warn(ASignManager.java:405)
     at com.telventi.afirma.cliente.signatureformat.signaturemanager.SignManagerMSIEWin32.signDigitally(SignManagerMSIEWin32.java:63)
     at com.telventi.afirma.cliente.signatureformat.CMSSignatureFormat.createSignedInfo(CMSSignatureFormat.java:1562)
     at com.telventi.afirma.cliente.signatureformat.CMSSignatureFormat.signExplicitHash(CMSSignatureFormat.java:265)
     at com.telventi.afirma.cliente.signatureformat.signaturemanager.ASignManager.signHashElectronically(ASignManager.java:139)
     at com.tsol.afirma5.util.impl.AppletServiceImpl.generarFirma(AppletServiceImpl.java:60)
     at com.tsol.validacionCertificado.applet.TSolApplet.obtenerFirmaGenerada(TSolApplet.java:105)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
     at java.lang.reflect.Method.invoke(Unknown Source)
     at sun.plugin.javascript.invoke.JSInvoke.invoke(Unknown Source)
     at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
     at java.lang.reflect.Method.invoke(Unknown Source)
     at sun.plugin.javascript.JSClassLoader.invoke(Unknown Source)
     at sun.plugin.com.MethodDispatcher.invoke(Unknown Source)
     at sun.plugin.com.DispatchImpl.invokeImpl(Unknown Source)
     at sun.plugin.com.DispatchImpl$1.run(Unknown Source)
     at java.security.AccessController.doPrivileged(Native Method)
     at sun.plugin.com.DispatchImpl.invoke(Unknown Source)
Caused by: com.telventi.afirma.cliente.exceptions.ClienteFirmaRuntimeException: Error al mapear el archivo de tipos.
     at com.telventi.afirma.cliente.utilidades.MimeTypeHelper.<init>(MimeTypeHelper.java:26)
     at com.telventi.afirma.cliente.utilidades.MimeTypeHelper.getInstance(MimeTypeHelper.java:32)
     at com.telventi.afirma.cliente.actions.ACommonAction.<clinit>(ACommonAction.java:59)
     ... 21 more
Caused by: java.lang.NullPointerException
     at java.util.Properties$LineReader.readLine(Unknown Source)
     at java.util.Properties.load(Unknown Source)
     at com.telventi.afirma.cliente.utilidades.MimeTypeHelper.<init>(MimeTypeHelper.java:23)
     ... 23 more
java.lang.Exception: java.lang.ExceptionInInitializerError
     at sun.plugin.com.DispatchImpl.invokeImpl(Unknown Source)
     at sun.plugin.com.DispatchImpl$1.run(Unknown Source)
     at java.security.AccessController.doPrivileged(Native Method)
     at sun.plugin.com.DispatchImpl.invoke(Unknown Source)
[SignApplet]: Invocando isInitialized.
Code where it fail is:
TYPES.load((com.telventi.afirma.cliente.utilidades.MimeTypeHelper.class).getResourceAsStream("mimetypes.properties"));
TYPES is Properties object.
When we modify the .java.policy file with permission java.security.AllPermission it work fine too, and this make to us think that this is a permission problem!.
Somebody has an idea???
Sorry for my english!

Having to modify the policy file defeats the whole point of using applets in the first place. If you have to install anything (such as a new policy file) on the client machine, you may as well install a GUI program.
Either get yourself a digital certificate and sign the applet, or use an independent program instead.

.java.policy file problem

Similar Messages

Maybe you are looking for