[jboss-dev] Refactoring packaging/packages to reduce "signed jar groups"

David M. Lloyd david.lloyd at redhat.com
Thu Feb 25 14:11:34 EST 2010


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



More information about the jboss-development mailing list