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?
>