Signed applets called from javascript - how/where to load policy file?

Question

I'm running into some apparently well-known problems with signed applets accessing a client machine's hard drive.
So, I can get things to work if I place the following two lines in my 'local' JDK installation:
permission java.io.FilePermission "${user.home}/x.properties", "read,write";
permission java.util.PropertyPermission "user.home", "read";These let me a) read the user's home directory and b) read/write a file that's located there.
What I don't want to do is edit the java.policy file, but I'm having problems loading a separate policy file. The app server we run with our product is jetty, and I'm assuming I would be passing in the '-Djava.security.policy=='filename' with the other jetty start-up parameters- is this a correct assumption? And, what path do I give for the file, will I need to put it somewhere in the .war file we distribute, or in the JDK installation on the server? If it's on the server, will client machine's know about these extra rights?
I'd REALLY appreciate any help I could get on this...
thanks in advance,
+0^^

Answer 1

Maybe you didn't realize but my previous post was sarcastically ment:
"hello SUN security stop bugging me in writhing this malicious program"
and
"hello SUN security, I'm a good boy now trust what I'm doing"
Are in a practical sense exactly the same.
SUN should either remove the stack check or the doprivileged. The stack check takes up
valuable resources for nothing since a malicious program can easily circumvent that.
Your post about a malicious user abusing your (CA) signed applet to ruine someone's
system is correct, it would not be difficult. A CA signed applet will not even ask a user to
trust or not. This is one of the reasons we have the usepolicy in affect, but this cannot be
used on "grandma's old PC" since it's too complicated for users to do such things.
YOU seem to be the one to blame, not the hacker! (The user accepted YOUR
certificate!).Actually you are to blame, because you made software that exposes a vonurability
other people can take advantage of.
what you can do before calling the doprivileged private method is check the call stack.
So your signed applet has a public method checking the callstack, if this lookes OK
that method will call the private doprivileged method.
Here is the example
package t;
import java.util.Properties;
import java.applet.Applet;
public class test extends Applet {
         public test(){
               startingPrivileged();
         public void startingPrivileged(){
               System.out.println("this is the stack");
               try{
                    throw new Exception("get the call stack");
               }catch(Exception e){
                    StackTraceElement stack[] = e.getStackTrace();
                    for (int i=0; i<stack.length; i++) {
                         System.out.println("file: " + stack.getFileName() + " method: " + stack[i].getMethodName() + " class: " + stack[i].getClassName() + " at " + new Integer(i).toString());
                    // this is a really simple check to see if this method was started from the t. package
                    // a good hacker can just create it's own package named t and take advantage of this method
                    // if this method was started from the same package there is no reason to make this method
                    // public, protected would work.
                    // there must be a better way to check if this method was called by "your" or "trusted" code
                    if(stack[1].getClassName().startsWith("t.")){
                         dosomePrivileged();
          private void dosomePrivileged(){
               System.out.println("this is the method that does privileged stuff");
     public static void main(String args[]) {
          new test();