Reading the policy file

[J. M.]

There's something I don't understand...

If I try to read a file, then a permission check is made on the policy
file that was loaded in memory. If the policy file says that I have
permission to read the file then the file is read. If not then the
file is not read.

That's good... but...

When Java loads the policy file in memory, it reads a file so how does
it do that if there is no policy file loaded in memory and therefore
it doesn't have the permission to read a file?

 

[Roedy Green]

When Java loads the policy file in memory, it reads a file so how does
it do that if there is no policy file loaded in memory and therefore
it doesn't have the permission to read a file?

Sun code is allowed to do many things that ordinary application code
is not. If it were not, it would never even get started.


I'm still trying to piece together how this all works.


My current guess is that sun booby traps the code in various critical
places saying in effect, "You must have permission X" to continue.

There are also calls of the form "Do I have permission X?" I want to
find out now before I dismantle the plumbing.

There is also some sort of proxy system where the code says, I may/may
not be permitted to do this, but I am doing on behalf of A, and A has
permission.

There is lots of detail, but I have not found something that explains
how it all fits together from a bird's eye perspective.

 

[Neomorph]

Sun code is allowed to do many things that ordinary application code
is not. If it were not, it would never even get started.

The policy file is loaded by the active SecurityManager, which sets the
security options according to the file - so the security isn't in place
until the file has been read.

I'm still trying to piece together how this all works.

It is quite well described in the documentation for the SecurityManager.

My current guess is that sun booby traps the code in various critical
places saying in effect, "You must have permission X" to continue.

No guessing neccessary, that is exactly how it works.

There are also calls of the form "Do I have permission X?" I want to
find out now before I dismantle the plumbing.

Classes like FileInputStream, URLConnection, etc. check with the security
manager if their actions are allowed before they continue. If not the throw
the SecurityException.

There is also some sort of proxy system where the code says, I may/may
not be permitted to do this, but I am doing on behalf of A, and A has
permission.

Actually, when Applets are signed, certain allowances can be given through
the Applet SecurityManager. The signing does not say 'on behalf of', it is
merely meant to identify the creator and the user can make a decision if he
trusts that creator enough to let the Applet do things it is normally not
allowed to do.
If the Applet does destroy your system or extracts private material and
sends it elsewhere (and you find out about it, of course), you can find the
SOB who programmed the Applet/got the certificate through the certifying
agency and kick him where you please.

There is lots of detail, but I have not found something that explains
how it all fits together from a bird's eye perspective.

Sun has quite in-depth documentation on these things, but they are quite
cumbersome to go through (very dry material - could compete with the Sahara
- just like the official docs on JavaBeans).


Cheers.

 

[Roedy Green]

What I was referring to was this piece of lucid prose:

Note that the checkPermission method with just a single permission
argument always performs security checks within the context of the
currently executing thread. Sometimes a security check that should be
made within a given context will actually need to be done from within
a different context (for example, from within a worker thread). The
getSecurityContext method and the checkPermission method that includes
a context argument are provided for this situation. The
getSecurityContext method returns a "snapshot" of the current calling
context. (The default implementation returns an AccessControlContext
object.) A sample call is the following:

Object context = null;
SecurityManager sm = System.getSecurityManager();
if (sm != null) context = sm.getSecurityContext();

 

[Roedy Green]

Sun has quite in-depth documentation on these things, but they are quite
cumbersome to go through (very dry material - could compete with the =
Sahara

Perhaps you can clear up a few mysteries.

Why is there a SecurityController.checkPermission and
AccessController.checkPermission? What's the difference?

what is doPrivileged for?

1. just a quick way to wrap some code in a permission test

2. a way to override the usual permission test, and permit the
operation even though it would usually fail.

3. It is for critical code that must have only one thread at a time
access?

4. It is just some more dynamic version of checkPermission?

5. Is this something for Sun code to use, or application code or both?

Why do they say to keep the run method of doPrivileged short? This
implies doPrivileged does some sort of synchronised lock.

 

[Roedy Green]

what is doPrivileged for?

Here is my best guess:

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.

String lineSeparator =
(String) java.security.AccessController .doPrivileged(
new sun.security.action.GetPropertyAction ( "line.separator" )) ;