From linuxhippy at gmail.com  Wed Nov  7 05:40:40 2007
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Wed, 7 Nov 2007 14:40:40 +0100
Subject: <AWT Dev> Bug in AWT's image-loading Security checking?
Message-ID: <194f62550711070540l161ae416s2ef031b3e1b90d04@mail.gmail.com>

Hello,

I recently stumbled over a strange issue with a signed applet when
loading images:

The following code throws a SecurityException:
new ImageIcon(new URL("http://juibrowser.sf.net/imgs/1.png")).getImage();

However this code works:
InputStream is = new URL("http://juibrowser.sf.net/imgs/1.png").openStream();
ByteArrayOutputStream bos = new ByteArrayOutputStream();
int read = 0;
while ((read = is.read()) != -1) bos.write(read);
new ImageIcon(bos.toByteArray()).getImage();

So in both cases java has to contact
http://juibrowser.sf.net/imgs/1.png, and although its deployed from
another server it should be allowed to do so in both cases because its
signed.


This is the Exception that has been thrown in the first case:
at java.lang.SecurityManager.checkPermission(SecurityManager.java:588)
	at java.lang.SecurityManager.checkConnect(SecurityManager.java:1104)
	at sun.awt.image.URLImageSource.checkSecurity(URLImageSource.java:97)
	at sun.awt.image.ImageRepresentation.imageComplete(ImageRepresentation.java:636)
	at sun.awt.image.InputStreamImageSource.errorConsumer(InputStreamImageSource.java:147)
	at sun.awt.image.InputStreamImageSource.setDecoder(InputStreamImageSource.java:308)
	at sun.awt.image.InputStreamImageSource.doFetch(InputStreamImageSource.java:262)
	at sun.awt.image.ImageFetcher.fetchloop(ImageFetcher.java:190)
	at sun.awt.image.ImageFetcher.run(ImageFetcher.java:154)

So I dig a bit into jdk7b19's source and found the evil lines:

In ImageRepresentation:
     public void imageComplete(int status) {
	if (src != null) {
	    src.checkSecurity(null, false);
	}
----
which calles into URLImageSource:
 final boolean checkSecurity(Object context, boolean quiet) {
	if (actualHost != null) {
	    try {
                SecurityManager security = System.getSecurityManager();
                if (security != null) {
                    security.checkConnect(actualHost, actualPort, context);
                }
	    } catch (SecurityException e) {
		if (!quiet) {
		    throw e;
		}
......

I am all but a professional when it comes to Java's security
management, but there are two strange things I wonder about:
1.) Why do we check wether we have checkConnect-privilleges, if the
image has already been loaded (just a guess because the method is
named "imageComplete"?
2.) Could it be that this thread somehow has the "wrong"
SecurityContext? So although the threads started by the signed applet
have the right to do teh connect, this thread has not?

For me this has absolutly no priority because the workarround is easy.
However if its a bug I could maybe contribute a fix...

lg Clemens


From linuxhippy at gmail.com  Wed Nov  7 11:13:12 2007
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Wed, 7 Nov 2007 20:13:12 +0100
Subject: <AWT Dev> Bug in AWT's image-loading Security checking?
In-Reply-To: <194f62550711070540l161ae416s2ef031b3e1b90d04@mail.gmail.com>
References: <194f62550711070540l161ae416s2ef031b3e1b90d04@mail.gmail.com>
Message-ID: <194f62550711071113o67e64413tf2c6791bb5c996c2@mail.gmail.com>

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?


From fitzsim at redhat.com  Thu Nov 22 12:58:31 2007
From: fitzsim at redhat.com (Thomas Fitzsimmons)
Date: Thu, 22 Nov 2007 15:58:31 -0500
Subject: <AWT Dev> [PATCH] memory leak in LCMS.c
Message-ID: <4745ED77.5080401@redhat.com>

Hi,

Java_sun_java2d_cmm_lcms_LCMS_loadProfile gets its data parameter's byte array 
elements but does not release them.  A fix is attached.

Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: icedtea-lcms-leak.patch
Type: text/x-patch
Size: 473 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20071122/fbced6c8/icedtea-lcms-leak.patch 

From Phil.Race at Sun.COM  Thu Nov 22 14:04:18 2007
From: Phil.Race at Sun.COM (Phil Race)
Date: Thu, 22 Nov 2007 14:04:18 -0800
Subject: <AWT Dev> [PATCH] memory leak in LCMS.c
In-Reply-To: <4745ED77.5080401@redhat.com>
References: <4745ED77.5080401@redhat.com>
Message-ID: <4745FCE2.4060802@sun.com>

This should be 2d-dev.

Alexey, can you take care of this.

thx,

-phil.

Thomas Fitzsimmons wrote:
> Hi,
>
> Java_sun_java2d_cmm_lcms_LCMS_loadProfile gets its data parameter's 
> byte array elements but does not release them.  A fix is attached.
>
> Tom
> ------------------------------------------------------------------------
>
> --- openjdk/jdk/src/share/native/sun/java2d/cmm/lcms/LCMS.c.orig	2007-11-17 11:07:47.000000000 -0500
> +++ openjdk/jdk/src/share/native/sun/java2d/cmm/lcms/LCMS.c	2007-11-17 11:12:47.000000000 -0500
> @@ -182,6 +182,8 @@
>  
>      sProf.pf = cmsOpenProfileFromMem((LPVOID)dataArray, (DWORD) dataSize);
>  
> +    (*env)->ReleaseByteArrayElements (env, data, dataArray, 0);
> +
>      if (sProf.pf == NULL) {
>          JNU_ThrowIllegalArgumentException(env, "Invalid profile data");
>      }
>   



From lists at munckfish.net  Wed Nov 28 02:33:37 2007
From: lists at munckfish.net (Dan Munckton)
Date: Wed, 28 Nov 2007 10:33:37 +0000
Subject: <AWT Dev> Java Fullscreen Exclusive Mode not working with Xorg
	server 1.3.0	and above
Message-ID: <1196246017.8431.23.camel@dylan>

Hi

I don't know if anyone here is already aware of this but I've discovered
a problem with Xorg server 1.3.0 (and above) which prevents use of Full
Screen Exclusive mode (FSEM) [0]. I came across this problem in Ubuntu
7.10 (Gutsy) but checking the upstream code I believe it may be present
in any Linux distro which uses that version or above.

>From discussion on the ubuntu-x mailing list [1] I've learned that work
is happening in Xorg to remove Xinerama altogether and replace it's
functionality with Xrandr. Apparently as various parts need to be
rewritten this process could take a couple of years.

As of Xorg server 1.3 the Xinerama backend implementation has been
replaced with an Xrandr one which now handles the Xinerama protocol [2].
Unfortunately this has changed the interface slightly; the real Xinerama
would not initialise if there is only 1 monitor [3], but the Xrandr one
now does [4].

>From studying the IcedTea/OpenJDK code [5] I see the Java native calls
that setup FSEM use Xrandr. However if Xinerama is active they rightly
avoid using Xrandr and therefore disable FSEM [6].

Because Xinerama now appears to be loaded even for single monitor setups
it seems FSEM is not possible.

I have been trying to find a work around for this. With the original
Xinerama implementation a flag could be set in xorg.conf to disable
Xinerama. However that no longer works with the Xrandr backend.

So at the moment only two possibilities occur to me:

  * Xorg's Xrandr Xinerama backend needs to be modified to behave as the
original one did. I will email the Xorg team and find out whether this
will be possible.

  * Or maybe could the code in awt_GraphicsEnv.c check if only 1 monitor
is connected and presume that it's the Xrandr backend that's in use as
Xinerama wouldn't be loaded in that situation?

Thanks

Dan Munckton

[0] https://bugs.launchpad.net/ubuntu/+source/sun-java6/+bug/154613
[1] https://lists.ubuntu.com/archives/ubuntu-x/2007-November/000061.html
[2]
http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=blob;f=randr/rrxinerama.c
[3] See PanoramiXExtensionInit(...) in
http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=blob;f=Xext/panoramiX.c
[4] See RRXineramaExtensionInit(void) in [2]
[5]
http://icedtea.classpath.org/hg/openjdk/file/3b9a53e0ec3c/jdk/src/solaris/native/sun/awt/awt_GraphicsEnv.c
[6] See Java_sun_awt_X11GraphicsDevice_initXrandrExtension() [5]



From lists at munckfish.net  Fri Nov 30 12:38:36 2007
From: lists at munckfish.net (Dan Munckton)
Date: Fri, 30 Nov 2007 20:38:36 +0000
Subject: <AWT Dev> Java Fullscreen Mode with Xorg server 1.3.0+
	(I'm	ready to work on a patch)
In-Reply-To: <1196246017.8431.23.camel@dylan>
References: <1196246017.8431.23.camel@dylan>
Message-ID: <1196455116.9594.7.camel@dylan>

> Or maybe could the code in awt_GraphicsEnv.c check if only 1 monitor
> is connected and presume that it's the Xrandr backend that's in use as
> Xinerama wouldn't be loaded in that situation?

I tested this out and of course it works on my single monitor setup. 

Since then I've chatted with Adam Jackson (Redhat) on #xorg he advised
that if XRRQueryVersion() returns >= 1.2, Java should go ahead and use
RANDR even if Xinerama is present.

So I'd like to go ahead and work on a patch for this. Could anyone
confirm if this is ok and that I'd not be duplicating effort?

I've still not opened a bug on the Java bug database, do I need to do
that to be tidy?

Any tips on how to go about writing a jtreg test for this?

Cheers

Dan




From Oleg.Sukhodolsky at Sun.COM  Fri Nov 30 18:38:42 2007
From: Oleg.Sukhodolsky at Sun.COM (Oleg Sukhodolsky)
Date: Sat, 01 Dec 2007 05:38:42 +0300
Subject: <AWT Dev> Java Fullscreen Mode with Xorg server
 1.3.0+	(I'm	ready to work on a patch)
In-Reply-To: <1196455116.9594.7.camel@dylan>
References: <1196246017.8431.23.camel@dylan> <1196455116.9594.7.camel@dylan>
Message-ID: <4750C932.3090908@sun.com>

Hi Dan,

am I right that your are going to fix our code so it correctly handled 
situation when Xinerama is loaded but we have just one screen, so we 
could use Xrandr extension in such configuration?

This code is somewhere on boundary of AWT and 2D areas so you may want 
to also check with 2D.  As for AWT side I can say for sure that we do 
not work on similar issue.

 > I've still not opened a bug on the Java bug database, do I need to do
 > that to be tidy?

you are supposed to send a path with bug id, so it looks reasonable to 
have one :)

Regards, Oleg.

Dan Munckton wrote:
>> Or maybe could the code in awt_GraphicsEnv.c check if only 1 monitor
>> is connected and presume that it's the Xrandr backend that's in use as
>> Xinerama wouldn't be loaded in that situation?
> 
> I tested this out and of course it works on my single monitor setup. 
> 
> Since then I've chatted with Adam Jackson (Redhat) on #xorg he advised
> that if XRRQueryVersion() returns >= 1.2, Java should go ahead and use
> RANDR even if Xinerama is present.
> 
> So I'd like to go ahead and work on a patch for this. Could anyone
> confirm if this is ok and that I'd not be duplicating effort?
> 
> I've still not opened a bug on the Java bug database, do I need to do
> that to be tidy?
> 
> Any tips on how to go about writing a jtreg test for this?
> 
> Cheers
> 
> Dan
> 
> 
> 


From Alexey.Ushakov at Sun.COM  Thu Nov 22 14:11:49 2007
From: Alexey.Ushakov at Sun.COM (Alexey Ushakov)
Date: Thu, 22 Nov 2007 22:11:49 -0000
Subject: <AWT Dev> [OpenJDK 2D-Dev]  [PATCH] memory leak in LCMS.c
In-Reply-To: <4745FCE2.4060802@sun.com>
References: <4745ED77.5080401@redhat.com> <4745FCE2.4060802@sun.com>
Message-ID: <4745FFEB.2010902@sun.com>

Yes, I'll look into it.

Best Regards,
Alexey

Phil Race wrote:
> This should be 2d-dev.
>
> Alexey, can you take care of this.
>
> thx,
>
> -phil.
>
> Thomas Fitzsimmons wrote:
>> Hi,
>>
>> Java_sun_java2d_cmm_lcms_LCMS_loadProfile gets its data parameter's 
>> byte array elements but does not release them.  A fix is attached.
>>
>> Tom
>> ------------------------------------------------------------------------
>>
>> --- openjdk/jdk/src/share/native/sun/java2d/cmm/lcms/LCMS.c.orig    
>> 2007-11-17 11:07:47.000000000 -0500
>> +++ openjdk/jdk/src/share/native/sun/java2d/cmm/lcms/LCMS.c    
>> 2007-11-17 11:12:47.000000000 -0500
>> @@ -182,6 +182,8 @@
>>  
>>      sProf.pf = cmsOpenProfileFromMem((LPVOID)dataArray, (DWORD) 
>> dataSize);
>>  
>> +    (*env)->ReleaseByteArrayElements (env, data, dataArray, 0);
>> +
>>      if (sProf.pf == NULL) {
>>          JNU_ThrowIllegalArgumentException(env, "Invalid profile data");
>>      }
>>   
>