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.
- 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?
- The permission declarations has to be a separate file. And I like
the idea to expand this mechanism to library jars subsequently.
- 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.
- M
On 10 May 2012 23:44, Bill Shannon <bill.shannon_at_oracle.com> wrote:
> Larry McCay, Ron Monzillo, and I have drafted updates to the platform
> spec to describe the new security manager requirements we've previously
> agreed on. It turned out to be surprisingly difficult to write these
> requirements in a way that captures some of the subtlety involved.
> Please review these updated spec sections carefully and ask questions
> if you're not sure exactly what the requirements are.
>
> The proposed spec updates are here, and will be folded into the draft
> spec soon (obviously the numbering and such will be fixed at that point):
>
> http://java.net/projects/javaee-spec/downloads/download/ee-sec-mgr-00-ljm.pdf
>
> Thanks.