Skip to main content

[jsr342-experts] Re: security permissions for libraries

  • From: Werner Keil <werner.keil@...>
  • To: jsr342-experts@...
  • Subject: [jsr342-experts] Re: security permissions for libraries
  • Date: Mon, 19 Nov 2012 14:09:42 +0100

I agree, #1 makes most sense right now.

Although this particular set of permissions is only for the Security Manager, not individual applications, I would prefer if the upcoming Configuration standards would take care of finer grained permissions, e.g. you might have one tenant where access to a certain resource is necessary while in another case yo may want to block that. Does not sound like a good idea to offer every single library JAR that option, those may contradict each other just the same way as you currently have dependency conflicts also known as JAR-Hell or Classpath-Hell

Regards,
-- 

Werner Keil JCP Executive Committee Member | Eclipse UOMo Lead | Java Godfather

Twitter @wernerkeil | #Java_Social | #EclipseUOMo | #OpenDDR

Skype werner.keil | Google+ gplus.to/wernerkeil

* Eclipse DemoCamp: November 21 2012, Copenhagen, Denmark. Werner Keil, Eclipse UOMo Lead and Mærsk Build Manager will present "Eclipse M2M and Standards for the IoT", "Eclipse STEM"

* Eclipse DemoCamp: November 26 2012, Berlin, Germany. Werner Keil, Eclipse UOMo Lead and Mærsk Build Manager will present "Eclipse M2M and Standards for the IoT"

* Eclipse DemoCamp: November 30 2012, Vienna, Austria. Werner Keil,  Eclipse UOMo Lead and Mærsk Build Manager will present "Triple-E class Continuous Delivery with Hudson, Maven, Kokki and PyDev"


On Mon, Nov 19, 2012 at 9:28 AM, Florent BENOIT <Florent.Benoit@...> wrote:
As for the Java EE 7 release permissions.xml wouldn't be available for libraries, a good start is to reuse the permissions of the caller which is the option #1.
For option #2 it will be quite difficult to customize permissions as we're always using defaults permissions so it would be quite useless.
Option #3 is not a fine-grained permission, all libraries sharing the same pattern so I don't think we should introduce this concept if in the next version we've permissions.xml support inside libraries : Because we will have to continue to support this strange concept in the next Java EE releases
So I think option #1 is the better to understand and is a simple rule.

Regards,

Florent

On Sat, Nov 17, 2012 at 1:18 AM, Bill Shannon <bill.shannon@...> wrote:
As described in this document:
http://java.net/projects/javaee-spec/downloads/download/ee-sec-mgr-00-ljm.pdf
we plan to add the ability to include a permissions.xml file with an
application to control what security permissions the application gets.

Our intent was to support this only at the module level, e.g., only for a
war file, ejb-jar file, or app client jar file.  This raises a question
I'd like your opinion on...

What permissions should apply to libraries in the "lib" directory of an
ear file?

Ultimately we'd like to allow each such library to include a permissions.xml
file of its own, but even then we need to decide what permissions should
apply if the library doesn't include a permissions.xml file.

Remember that libraries are available to all modules of the application.

There seem to be a few options:

1. The permissions for the library are the same as the permissions for
   the code that calls the library.  If the library code is called from
   a war file, it gets the permissions of the war file.  If the same
   library is called from an ejb-jar file, it gets the permissions of
   the ejb-jar file.

2. The permissions for the library are the default permissions for the
   container calling the library.  As above, the permissions would vary
   based on what code calls the library, but would always be the default
   permissions for that container, even though the calling code might
   have more or fewer permissions than the default.  (It's not clear to
   me that this is implementable.)

3. We allow a permissions.xml file to be included in the "lib" directory.
   All the libraries in the "lib" directory get these permissions, no
   matter which container is calling them.

Note that in addition to libraries in the "lib" directory of an ear file,
modules can use a Class-Path entry to reference other libraries anywhere
in the ear file.  I think #1 above is the only viable choice for this
case.

Again, in a future release we hope to support a permissions.xml file in
the library jar file itself.

How do you think we should handle security permissions for libraries in
this release?





[jsr342-experts] security permissions for libraries

Bill Shannon 11/17/2012

[jsr342-experts] Re: security permissions for libraries

Werner Keil 11/17/2012

[jsr342-experts] Re: security permissions for libraries

Florent BENOIT 11/19/2012

[jsr342-experts] Re: security permissions for libraries

Werner Keil 11/19/2012
 
 
Close
loading
Please Confirm
Close