It happens only to some images, I must admit. I decompiled the
ToolkitImage and URLImageSource classes to see what are the
parameters and found that security context is always set to NULL and
the default SecurityManager implementation throws SecurityException
if the context is not of an AccessControlContext type. In other
words, it means that there should always be an exception, but there's
not and it's puzzling me a bit.
Security debug might be useful. I Googled this up related to it. You
could probably come up with more formal documentation somewhere.
Anyway, the main question is connected with what I decided to do. I
decided to install my own SecurityManager implementation on
application startup through the System.setSecurityManager() call. My
implementation *never* throws SecurityException. I realize that some
security managers installed by the system before my re-installation
attempt could refuse to be replaced, but it's not the point. I'm
feeling a bit uneasy about whether there are any negative
implications connected with a security manager always saying 'Yes'.
Does anyone have any experience with this?
I think defining an all permissions security policy is the more modern
way to do this. Messing with SecurityManager is supposed to be sort of
old-fashioned. I do it too though in an application that is supposed
to run arbitrary java code so that I can trap System.exit and keep it
from shutting down my application. I don't think I do anything else
with it. Also I might be wrong but I think it is no longer true that
you can't replace an established SecurityManager.
Hm. Nice idea about the all-permissions security policy. I believe,
there's a situation when a system SecurityManager would refuse replacing
itself -- when you run an unsigned JWS application or an applet, so that
the system controls where you look and where you connect. In all other
cases, whole security thing looks pointless to me as it can be easily
disabled.
Thanks, Mike, for your comments! Any other thoughts?
