jsr342-experts@javaee-spec.java.net

[jsr342-experts] Re: spec changes for new security manager requirements

From: Bill Shannon <bill.shannon_at_oracle.com>
Date: Tue, 15 May 2012 11:45:53 -0700

Markus Eisele wrote on 05/10/12 22:15:
> Hi Bill,
> hi all,
>
> Thanks for the effort! It looks great. Here is my feedback:
>
> - I like (!) the short tag names! :) And I still like to have a
> <xs:element type="xs:string" name="description" minOccurs="0"/> in
> the schema. Some admin UI will display the permissions.xml in a
> beautified format and would be happy to have this tag.

Yes, that seems like a reasonable suggestion.

> - I checked with some installations I know and the property expansion
> still is something I believe is of value here. Going further looking
> at EE.6-2 and the [1] comment I would propose to define a couple of
> default properties that should be available.
> a) application specific temp dir (the javax.servlet.context.tempdir)
> b) application working directory (expanded deployments)
> c) "user home" (to read additional, external configuration files)
> Any further ideas/thoughts here?

We're still considering this, but at this point it looks like more work
than we can do for this release.

> - The permission declarations has to be a separate file. And I like
> the idea to expand this mechanism to library jars subsequently.

In the past we've gotten consistent feedback that any new deployment information
should be included in the existing deployment descriptors, rather than creating
new descriptors for each new bit of deployment information. Clearly we can make
it work either way, and each has advantages, but I'd like to hear from others
on this as well.

> - there is one thing that I would like to discuss further:
> EE.6.2.2.1 => 4th §:
> "If an application module does not contain a declaration of required
> security permissions and deployment otherwise succeeds, the Java EE product
> must grant the application components the permissions established by
> the security
> policy of the installation. "
>
> and 5th §
> Note that, on some installations of Java EE products, the security
> policy of the installation may be such that applications are granted
> fewer permissions than
> those defined in Table EE 6-2 and ...
>
> I strongly believe that the minimum rights for an application missing
> a permissions.xml should be the EE 7 platform default (Table EE.6-2).
> It doesn't make any sense to me to successfully deploy an application
> which isn't able to run because of the security policy of the
> installation. And yes, I have read the 2nd § in the same chapter and
> you are right. So I am with Adam here, that we
>
>> "force" the application server vendor to provide a prepared policy with the restrictions defined in the Java EE / EJB specs.
>
> And I would even go further and define one for each profile.
>
> #1 reason is to make it dead simple for developers to install a server
> with the appropriate (minimum Java EE 7) rights. Messing around with
> such a detailed security configuration is something that shouldn't
> hinder anybody writing a Java EE 7 application. Security isn't funny
> and never will be. Let's hide it as much as possible.

Preventing administrators from configuring a local security policy that
excludes certain expected Java EE security permissions would be an
incompatible change to the spec. Vendors could no longer allow administrators
to configure the product as they used to be able to.

We've tried to make it even more clear that if an administrator does take
advantage of this capability, there might be some applications that can
not run in that configuration. But our experience has been that security
people feel very strongly that they know what's best for their local
environment and we shouldn't prevent them from configuring more or less
security than applications typically expect.