Bill/all,
Aside from questions the other EGs shall be able to discuss (e.g. if the
likes of 351 would pick up a Java EE SecurityManager or need to declare
their own JSR-specific one) I strongly agree with the separate file
location at least as an alternative to inside an application archive (WAR,
EAR,...)
This makes it much easier, for real life build and configuration management
teams to adjust that e.g. from a stage like *"Test"* to *"PreProd"* or *
"Prod"* without having to rebuild the entire application, if security is
the only one that changes.
Werner
On Fri, May 11, 2012 at 7:15 AM, Markus Eisele <myfear_at_web.de> wrote:
> 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.
>