The policyfile controls what every program can and cannot do. It is a global file that sets overall security policy, not a file per program. It is thus difficult to get changed. Normally a system administrator installs the same policyfile on nearly every desk in the institution.
The most important thing to understand is that nothing you put in your code grants you any additional privilege. It is all decided by the policyfile.
I have not used Sun’s code signing scheme extensively. It seems though that, unlike Netscape’s scheme, you don’t pepper your application code with permission requests. You just go ahead and do what you want to do, and deal with any permission failure exceptions. You may do checks to ensure you have sufficient permission before you start some complex action, but that is not required. You, as application programmer, don’t have to ask for permission first the way you with the Netscape and Microsoft schemes.
However, if you want to know in advance just what will succeed, you can use Permissions.
In contrast, Sun’s library code is boobytrapped all over with code of the form You cannot continue unless you have permission X. If you examine the code for FileInputStream or URLConnection, you can see them checking with the SecurityManager if the actions the plan are allowed before they continue. If not they throw a SecurityException.
// Code from URLConnection checking that user has the right to // modify the factory that produces Socket Objects. // It throws a SecurityException if you don't have sufficient privilege. SecurityManager security = System.getSecurityManager(); if ( security != null ) { security.checkSetFactory(); }A more generic check is SecurityManager.checkPermission. AccessController.checkPermission appears to have the identical function.
Sun’s code, may have privilege, even though the caller of the code may not. Sun’s code can say in effect, it does not matter if the caller has sufficient privilege, I do, and I vouch that what I am doing on the caller’s behalf is safe. If you trust me, trust that this is safe, even if you don’t trust the caller. Here is an example in Sun’s code in PrintWriter of checking permission to look at the line.separator system property. It permits the operation if the PrintWriter code has permission even if the caller does not.
With Java Web Start, you can check your permissions even before your code loads with XML statements in the JNLP file.
There is detailed documentation on the various security classes such as Permission and SecurityManager but I have not found anything that gives a bird’s eye introduction to how it all fits together. You have to piece it together from the class documentation. This whole area could desperately use a tutorial. All I have done is give you some clues. If find out how this all works, please let me know.
![]() |
and suggestions to improve this page to Roedy Green : | ||
| Canadian Mind Products | |||
| mindprod.com IP:[65.110.21.43] | |||
| Your face IP:[38.103.63.16] | The information on this page is for non-military use only. | ||
| You are visitor number 8,353. | Military use includes use by defence contractors. | ||
| You can get a fresh copy of this page from: | or possibly from your local J: drive (Java virtual drive/Mindprod website mirror) | ||
| http://mindprod.com/jgloss/permission.html | J:\mindprod\jgloss\permission.html | ||