Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#25 improve robustness under J2EE

open
nobody
4
2003-07-13
2002-10-30
Anonymous
No

This is a follow-on to a message,
http://sourceforge.net/mailarchive/forum.php?
thread_id=1197319&forum_id=1472
to the SAX developer list. I'm hoping this way to ensure
this doesn't fall off everyone's radar.

Discussion

  • Logged In: NO

    Sorry; an obvious duplicate of 631290
    ; for the record I also attempted to attach a file to both
    reports, but it would seem my browser wasn't up to it. :(

     
  • David Brownell
    David Brownell
    2002-10-31

    Logged In: YES
    user_id=44117

    To summarize, the issue seems to be that some J2EE
    environments emit
    lots of spurious diagnostics from their security policy
    engines because the
    portable bootstrapping uses its execution environment.

    For all that Xerces ships code like this (but is out-of-date
    with respect
    even to the original set of SAX 2.0 bugfixes), I'm hesitant
    to describe
    this as an issue with anything other than those security
    policy engines,
    which are causing false alarms. If there's a real problem
    with SAX it
    should be mentioned in the RFE.

     
  • Neil Graham
    Neil Graham
    2002-11-01

    Logged In: YES
    user_id=640060

    The severity of the problems this causes are proportional to
    the completeness of the security implementation in the J2EE
    environment. In older environments, log messages would
    simply get issued, but in more modern ones (Websphere
    Application Server 5 beta, for instance), my understanding is
    that the current SAX code would immediately provoke a
    SecurityException when attempting to get system properties
    or look in jar meta-inf/services entries. Even if the code were
    rewritten to add catch blocks for these cases, such
    operations would still not complete even if the parser lies at
    the heart of the J2EE engine.

    The only way to allow such security-sensitive operations to
    be completed by code lying at the heart of the J2EE platform
    is for that code to use the AccessController's doPrivileged(...)
    method. Then the AccessController can determine the
    context of the caller, determine that it in fact is part of the
    installation and not some foreign code, and allow the
    operation to continue--so the code can behave as advertised.

    Now I'm a parser guy, not a J2EE security guru; so let me
    know if you need any more precise details, and I'll do what I
    can. But this is the way JAXP has gone, which should
    provide an independent, validating perspective on the
    problem. There also don't appear to be too many drawbacks,
    other than a certain partial decommitment from JDK 1.1.8;
    but surely this is a step the API will need to take at some
    point as the Java language continues to evolve.

    As to Xerces's being back-leveled w.r.t. SAX: that's true, but
    orthogonal IMHO; at all events it would be nice if Xerces was
    strictly back-level and didn't have to implement extended
    functionality such as this. The upgrade path would then be
    clear to take as soon as we need no longer conform to the
    JAXP 1.2 TCK. Rest assured Xerces would have updated its
    support by now if that were possible.

     
  • David Brownell
    David Brownell
    2003-07-13

    • priority: 5 --> 4
     
  • David Brownell
    David Brownell
    2003-07-13

    Logged In: YES
    user_id=44117

    one more point: the SAX API specification clearly doesn't
    specify how the portable bootstrapping is done. It'd be
    perfectly reasonable for some implementation of SAX2
    to ship with code that didn't make the jdk 1.2+ security
    engines get all weepy -- so long as the SAX API was met.

    That is, this is a quality-of-implementation issue, it's
    not an API/interface issue. Any J2EE vendor would
    be well within its rights to change how that logic is
    implemented.