J2EE 1.4 Platform Specification Errata
	Java Authorization Contract for Containers 1.0 Errata
         March 18, 2004

J2EE defines a security model and requirements that cover both access
to the services and applications in a J2EE application server, as well
as the security environment in which J2EE applications execute.  The
security environment is controlled by the Java security manager and
the permissions granted to applications.  The J2EE spec defines a set
of security permissions that applications can expect.  The spec also
allows a vendor of a J2EE product, as well as users of the product, to
control the exact set of permissions available to an application,
either more or less than the minimum set, as long as it's possible
to grant the application at least the minimum set.  This has provided
the operational flexibility that customers require to choose the
appropriate security policy for their needs.

J2EE 1.4 added the following requirement (section 6.2.1, page 88):

         To ensure the integrity of J2EE containers, all J2EE containers
         must install a security manager and must prevent applications
         from replacing or overriding the security manager.

It has been pointed out that this requirement is in conflict with
the intent of the J2EE spec to allow customers to choose the security
policy for their needs.  It's also in conflict with current practice
which routinely allows applications to run with no security manager
at all.  In some environments the protections provided by a security
manager are less important than the performance cost of using a
security manager.  Customers demand the ability to make these
tradeoffs between protection and performance.

The clear majority opinion of the J2EE 1.4 expert group was that the
addition of this requirement was a mistake and should be removed.

This errata corrects this conflict in the J2EE spec by removing the
above quoted requirement.

JSR-115 (Java Authorization Contract for Containers) has echoed this
requirement in its specification.  That specification must be corrected
as well to eliminate this conflict.  In particular, the following changes
to the JSR-115 specification are required:

   Requirement #9 in section 1.4 is changed to:

         9. For a container to support this contract, it must execute in
            an environment controlled by a J2SE SecurityManager.
            Containers may also execute in environments that are not
            controlled by a J2SE SecurityManager. Section 1.5, "Running
            Without a SecurityManager" defines changes to this contract
            that apply to containers running without a J2SE
            SecurityManager.

Section 1.5 is added:

         1.5 Running Without a SecurityManager

         The following list defines changes to this contract that apply
         to containers running without a J2SE SecurityManager.

             1. The restrictions defined in Section 3.3, "Permission to
                Configure Policy" need not be enforced. Also, the
                containers of the application server must not be denied
                permission to perform any operation that would have been
                permitted in the presence of a SecurityManager.

             2. Such containers are not required (before dispatching a
                call) to associate an AccessControlContext with the call
                thread (as otherwise required by Section 4.1.2,
                "Pre-dispatch Decision" and Section 4.3.1, "EJB
                Pre-dispatch Decision").

             3. When performing the operations defined in Section 4.7,
                "Checking AccessControlContext Independent Grants" and
                in Section 4.8, "Checking the Caller for a Permission",
                such containers must not employ the
                SecurityManager.checkPermission and
                AccessControlContext.checkPermission techniques defined
                in these sections.

Changes to a specification after final release must always be done
with the greatest care, even when correcting an error in the spec.
The impact of the change on vendors and customers must be taken into
account.  In this case, the risk of this change appears relatively
low.  This change will not require any vendor to make any change
to an existing product implementing this specification.  It will
not require any changes to the J2EE CTS.  It is extremely unlikely
that it will disrupt any existing customer applications.  (It's
possible, but unlikely, that an application could depend on a
security manager always being installed, even though most existing
products do not do so.)  This change allows vendors to continue to
deliver J2EE 1.4 products in the same way they have delivered J2EE
1.3 products, with optional use of a security manager.  Vendors
who prefer to enforce more rigorous security requirements will
continue to be free to do so.