That's an interesting point. Will look into it as we have lots of use cases
for permissions in our corporate cloud. It would be great, if e.g. the
admin consoles of the most common containers like GlassFish, JBoss,
WebLogic, WebSphere, Geronimo, etc. would standardize on such a file,
too;-)
Without sharing too much here, but some in the EG sure heard, there is an
effort on configuration, in future releases I would care a lot less about
hard-wired, possibly contradicting permissions in a library JAR than
getting to configure that via a "Configuration JAR" that may be separately
injected into the class path, at least per tenant and for most containers
ideally at runtime without having to rebuild or -deploy the actual
application.
Werner
Am 17.11.2012 01:18 schrieb "Bill Shannon" <bill.shannon_at_oracle.com>:
> 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?
>