Security violation with Sun's JRE1.3, but not with JRE1.2.2

[Armand Liberi <al...@acutronic.com>]

Hello,

Several weeks ago, I submitted a bug to Sun which was assigned #4338954 and is now listed on their Bug Parade.  It concerns the use of Apache XML parser class files that worked with JRE1.2.2 but get security violations with JRE1.3.  It was subsequently determined by Sun not to be a bug in the JVM but rather a bug in the unchanged Apache parser class files. Could it be true?  The problem exists with files from the IBM site and with the version 1.1.1 files from the Apache site.

If this is not the proper place for this comment, please let me know where to send it.  I tried to report it  on page http://xml.apache.org/overview.html but was denied access.  Thanks.

Regards,
Armand

Re: Security violation with Sun's JRE1.3, but not with JRE1.2.2

[Armand Liberi <al...@acutronic.com>]

Andy,

You are absolutely correct! I did mean to type 'parser.parse(source)', not
'parser.parse(fname)'.  Sorry.  So, to set things straight, here's the exact
chunk of code that generates the exception:

// Start IBM suggestion
   FileInputStream fis=new FileInputStream(fname);
   InputSource source=new InputSource(fis);
   source.setSystemId(fname);
   parser.parse(source);
// Stop IBM suggestion

I think that I just cut and pasted it from your suggestion.  Now here's the
code that works just prior to execution of the above:

//    This code functions as expected before the chunk above executes.
   FileInputStream fis=new FileInputStream(fname);
   byte[] b=new byte[100];
   fis.read(b);
   Say("File " + fname + " successfully read as FileInputStream");
   InputSource source=new InputSource(fis);
   InputStream is=source.getByteStream();
   is.read(b);
   Say("File " + fname + " successfully read as InputStream");
   is.close();
   fis.close();
//    End of code that works.

I have written back to Sun about this twice, but can't seem to get their
interest.  I had hoped that a developer from Sun with some knowledge of the
source code at both ends would be participating in this group and actually
try out the code that I posted.  I would be happy to send the entire file as
it stands to anyone interested.  At this point, Sun points at Apache;
Apache points at Sun!  I have no idea how these things get resolved.

Again, I'm sorry for the mistake in my last post.

Regards,
Armand

----- Original Message -----
From: "Andy Clark" <an...@apache.org>
To: <xe...@xml.apache.org>
Sent: Wednesday, June 14, 2000 1:10 PM
Subject: Re: Security violation with Sun's JRE1.3, but not with JRE1.2.2


> Armand Liberi wrote:
> > However, the 'parser.parse(fname);' still generates an exception.
>
> If you're going to disregard my suggestion, then please don't
> continue to post "bug" reports that relate to security permissions
> in an Applet. I'll repeat: If you are able to open and read a file
> using a FileInputStream, then USE IT IN AN INPUTSOURCE OBJECT.
>
> Refer to my previous posting for an example:
>
>  http://xml-archive.webweaving.org/xml-archive-xerces-j-dev/0721.html
>
> --
> Andy Clark * IBM, JTC - Silicon Valley * andyc@apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
>

Re: Security violation with Sun's JRE1.3, but not with JRE1.2.2

[Andy Clark <an...@apache.org>]

Armand Liberi wrote:
> However, the 'parser.parse(fname);' still generates an exception.

If you're going to disregard my suggestion, then please don't
continue to post "bug" reports that relate to security permissions
in an Applet. I'll repeat: If you are able to open and read a file
using a FileInputStream, then USE IT IN AN INPUTSOURCE OBJECT.

Refer to my previous posting for an example:

 http://xml-archive.webweaving.org/xml-archive-xerces-j-dev/0721.html

-- 
Andy Clark * IBM, JTC - Silicon Valley * andyc@apache.org

Re: Security violation with Sun's JRE1.3, but not with JRE1.2.2

[Armand Liberi <al...@acutronic.com>]

Hello again,

As proposed, I have been able to successfuly read the file as a
FileInputStream and as an InputStream after:

   InputStream is=source.getByteStream();

with the suggested code.

However, the 'parser.parse(fname);' still generates an exception.  It
appears to be some problem with security but I cannot find any references to
changes from JRE1.2.2 to JRE1.3 that would explain it.  AFAIK, an applet
should be able to access the local file system if that is where the codebase
is located.  In fact, the example that I provided demonstrates that - except
in the case of 'parser.parse(fname);'

And, incidentally, a similar file that uses Sun's JAXP parses the file
without exceptions.

Regards,
Armand

----- Original Message -----
From: "Andy Clark" <an...@apache.org>
To: <xe...@xml.apache.org>
Sent: Tuesday, June 13, 2000 4:14 PM
Subject: Re: Security violation with Sun's JRE1.3, but not with JRE1.2.2


>
> If it is able to access the file using the FileReader, then File-
> InputStream should work as well. Assuming that it does, then there
> is no difference between the two because you are opening the file
> and the parser is just reading from it.
>
> As a sideline point: you shouldn't be opening files via FileReader/
> InputStream in an Applet. Unless, of course, that you have gone
> through the hassle of setting up the security options, etc. and the
> Applet code is "trusted".
>
> --
> Andy Clark * IBM, JTC - Silicon Valley * andyc@apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
>

Re: Security violation with Sun's JRE1.3, but not with JRE1.2.2

[Andy Clark <an...@apache.org>]

Armand Liberi wrote:
> Thanks for the suggestion.  Unfortunately, the same thing happened - it
> works with JRE1.2.2 and gets a security violation with JRE1.3.
> 
> Incidentally, the FileReader was added just to demonstrate that the file
> could be accessed that way.

If it is able to access the file using the FileReader, then File-
InputStream should work as well. Assuming that it does, then there
is no difference between the two because you are opening the file
and the parser is just reading from it.

As a sideline point: you shouldn't be opening files via FileReader/
InputStream in an Applet. Unless, of course, that you have gone
through the hassle of setting up the security options, etc. and the
Applet code is "trusted".

-- 
Andy Clark * IBM, JTC - Silicon Valley * andyc@apache.org

Re: Security violation with Sun's JRE1.3, but not with JRE1.2.2

[Armand Liberi <al...@acutronic.com>]

Andy,

Thanks for the suggestion.  Unfortunately, the same thing happened - it
works with JRE1.2.2 and gets a security violation with JRE1.3.

Incidentally, the FileReader was added just to demonstrate that the file
could be accessed that way.

So, ...

Regards,
Armand

----- Original Message -----
From: "Andy Clark" <an...@apache.org>
To: <xe...@xml.apache.org>
Sent: Tuesday, June 13, 2000 1:46 PM
Subject: Re: Security violation with Sun's JRE1.3, but not with JRE1.2.2


> Armand Liberi wrote:
> > Several weeks ago, I submitted a bug to Sun which was assigned
> > #4338954 and is now listed on their Bug Parade.  It concerns the use
> > of Apache XML parser class files that worked with JRE1.2.2 but get
>
> I would disagree with their assessment that the problem lies with
> the Xerces parser classes. Xerces, like all other Java code, and
> especially Applets, are subject to the restrictions imposed by
> the security manager.
>
> Your sample program that you posted as part of your bug report
> has two separate code paths for accessing the file. The first
> uses the java.io.FileReader class while the other allows Xerces
> to try to locate the file via a System URI.
>
> I don't know why the one code path is now restricted in JRE 1.3
> for the browser plug-in, but if you know that FileReader works,
> then use that instead. Here's an example:
>
>   // import org.xml.sax.InputSource;
>
>   String fname="f:/xml/LittleTests/TryXJParser2/personal.xml";
>   FileInputStream fis = new FileInputStream(fname);
>   InputSource source = new InputSource(fis);
>   source.setSystemId(fname);
>   parser.parse(source);
>   fis.close();
>
> Note that I use a FileInputStream and not a FileReader. By using
> a FileReader, you are telling the parser that the application is
> responsible for decoding the incoming bytes. Therefore, for any-
> thing other than ASCII text, the parser will not be able to
> properly decode the bytes into characters. Therefore, *always*
> use an input stream when you don't know what the encoding is and/
> or don't intend on decoding the bytes yourself.
>
> --
> Andy Clark * IBM, JTC - Silicon Valley * andyc@apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
>

Re: Security violation with Sun's JRE1.3, but not with JRE1.2.2

[Andy Clark <an...@apache.org>]

Armand Liberi wrote:
> Several weeks ago, I submitted a bug to Sun which was assigned
> #4338954 and is now listed on their Bug Parade.  It concerns the use
> of Apache XML parser class files that worked with JRE1.2.2 but get

I would disagree with their assessment that the problem lies with
the Xerces parser classes. Xerces, like all other Java code, and
especially Applets, are subject to the restrictions imposed by
the security manager.

Your sample program that you posted as part of your bug report
has two separate code paths for accessing the file. The first
uses the java.io.FileReader class while the other allows Xerces
to try to locate the file via a System URI.

I don't know why the one code path is now restricted in JRE 1.3
for the browser plug-in, but if you know that FileReader works,
then use that instead. Here's an example:

  // import org.xml.sax.InputSource;

  String fname="f:/xml/LittleTests/TryXJParser2/personal.xml";
  FileInputStream fis = new FileInputStream(fname);
  InputSource source = new InputSource(fis);
  source.setSystemId(fname);
  parser.parse(source);
  fis.close();

Note that I use a FileInputStream and not a FileReader. By using
a FileReader, you are telling the parser that the application is
responsible for decoding the incoming bytes. Therefore, for any-
thing other than ASCII text, the parser will not be able to 
properly decode the bytes into characters. Therefore, *always*
use an input stream when you don't know what the encoding is and/
or don't intend on decoding the bytes yourself.

-- 
Andy Clark * IBM, JTC - Silicon Valley * andyc@apache.org