Re: [jboss-dev] Refactoring packaging/packages to reduce "signed jar groups"
On 02/25/2010 12:59 PM, Adrian Brock wrote:
On Thu, 2010-02-25 at 12:25 -0600, David M. Lloyd wrote:
> On 02/25/2010 11:43 AM, Adrian Brock wrote:
>> On Thu, 2010-02-25 at 11:17 -0600, David M. Lloyd wrote:
>>>> One possible workaround solution would be to allow you to somehow
>>>> specify that the unsigned jar should create its own local package.
>>>> i.e. instead of searching the ClassLoaderDomain for the existing package
>>>> you just create one locally.
>>>
>>> Out of curiosity, is there a reason we don't do this already (i.e. a
javaee
>>> spec or something)? I'd think that by default each JAR should have a
>>> separate package space, but I guess there could be exceptions in certain
cases.
>>>
>>
>> Package sealing wouldn't work. It would see them as two
>> separate packages.
>
> Isn't that a good thing? Or are split packages a lot more pervasive than I
> thought? Packages are usually sealed with respect to a single JAR anyway,
> aren't they?
I don't understand your question?
Why is it a good thing to break to break this security feature? :-)
The purpose of sealing a package is to stop somebody else
in the same visible classloading space from adding to your package.
If each deployment used its own package space there would be no way
to enforce it - except when the two jars are in the same
deployment/classloader and hence shared the same package object.
My understanding is that if the Packages are not equal, then
package-protected access checks across JAR boundaries would fail, which is
what we'd want. I.e. you're strengthening security, not weakening it.
The JVM spec says "Each such class or interface belongs to a single runtime
package. The runtime package of a class or interface is determined by the
package name and defining class loader of the class or interface." which I
take to mean Package object, since Package objects are unique per
classloader. So you'd have one classloader per JAR with completely
segregated Package spaces, possibly within the same domain, thus allowing
individual JARs to be sealed.
Perhaps I've missed something in the conversation though, it wouldn't be
the first time.
- DML