From: Werner Keil <werner.keil_at_gmail.com>
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_at_ow2.org>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_at_oracle.com>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?
>>
>
>