<AWT Dev> Bug in AWT's image-loading Security checking?

[Clemens Eisserer]

Hi again,

I played a bit with JDK's source and researched a bit and I think I
was able to nail down the problem.

1.) The URL which refers to my image is redirected, the
redirection-logic is in URLImageSource.getDecoder
The original URL is: http://juibrowser.sf.net/imgs/1.png
The redirected URL is: http://juibrowser.sourceforge.net/imgs/1.png

2.) The ImageConsumerQueue associated with my
Image/ImageRepresentation does not have a securityContext set.

3.) When calling InputStreamImageSource.setDecoder, it loops over all
consumers in that queue calling checkSecurity.
If the image-url is not redirected this call does nothing, because
there's a check in URLImageSource.checkSecurity wether the URL was
redirected. (It only needs to be checked twice when the original URL
was redirected to another one). Thats why it works for not-redirected
images.

For redirected images this calls SecurityManager.checkConnect with
context=null, which accordingly to Securitymanager's source immediatly
leads to a SecurityException.

So there are two possible solutions/problems:

1.) Modify the call to checkConnect in checkSecurity, to not specify a
Security-Context if context=null. I don't know wether this could lead
to security problems. I guess it would use the default context instead
a specified one - could this be problematic?

URLImageSource.checkSecurity:
SecurityManager security = System.getSecurityManager();
if (security != null)
{
   if(context != null)
   {
        security.checkConnect(actualHost, actualPort, context);
    }else
   {
        security.checkConnect(actualHost, actualPort);
   }
}

2.) Check why the context of the ImageConsumerQueue is null - is that
a valid configuration?

It would be great if somebody could loose some words about how this is
expected to work and wether solution 1.) could cause problems.

lg Clemens

PS: Another potential "problem" I found is:
When the URL is redirected, the new port and the new hostname is
queried. However if somebody does not specify a port in the URL the
call to URL.getPort() returns -1, although the user ment port 80.

However later in checkSecurity the port-value is passed to the
SecurityManager - and its still -1 instead of 80. Worse the
SecurityManager handle's ports with -1 with a special case accordin to
javadoc:
> This method calls checkPermission with the
> SocketPermission(host+":"+port,"connect") permission if the port is not equal to -1.
> If the port is equal to -1, then it calls checkPermission with the
> SocketPermission(host,"resolve") permission.

At least as far as I can see the code does not anymore do for whats
intended. Could that be a problem?