river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Implications for Security Checks - SocketPermission, URL and DNS lookups
Date Fri, 23 Dec 2011 02:06:38 GMT
There's another way around poorly written equals() and hashCode() 
implementations.

In my reference collection utilities, I have strong, weak and soft 
references, there are variations on these based on identity or equality.

Well, I've just thought of another that might help out when poor equals 
implementations exist:

toString()?

first check both objects have the same class, then compare the results 
of toString(), and use toString().hashCode() for hashCode's.

I could call this String equality, when toString isn't overridden it 
prints the reference address so this is compatible with identity based 
equality also.

This would fix all those nasty equals implementations for use in 
collections without requiring any work on the developers part.

Cheers,

Peter.


Peter wrote:
> SocketPermissionCollection adds SocketPermission at the head of its internal list.  This
change was made in jdk 1.2.2_005  bug 4301064 related to reverse dns lookup delays for applets.
>
> This indicates that the tail of the last policy file parsed, is added last to the policy
and hence at the head of that List.
>
> It's  also worth noting that the standard policy provider included with the jvm is in
force until the preferred policy provider is completely initiated, after reading all policy
files.  So it's likely that the standard java policy is read last by our policy provider implementation.
>
> In summary a list of SocketPermissions need to be sorted beginning from those that cause
long dns delays, to wildcard based permissions, so the wildcard perms are added last and hence
checked first by any implies calls.
>
> I've got two options on how to solve this:
>
> 1.  Get rid of PermissionCollection based caches altogether and generate PermissionCollection's
on demand.
>
> 2  Replace the PermissionCollection cache with a List<Permission> based cache,
generate Permissioncollection's on demand.  Sort the List after creation, before publishing,
replace the list on write.
>
> Option 2 could be implemented in ConcurrentPermissions, a replacement for java.security.Permissions.
>
> Option 1 would be implemented by the policy.
>
> In addition, to allow the security manager to cache the results of permission checks
for SocketPermission, I can create a wrapper class, where equals and hashcode are based purely
on the string representation.  This allows very rapid repeated permission checks.
>
> Looks like I can get around the SocketPermission, CodeSource and URL headaches, relatively
unscathed.  
>
> N.B. Anyone care to try out, or seriously performance test the new PreferredClassProvider?
>
> Cheers,
>
> Peter.
>
> ----- Original message -----
>   
>> Actually, more significantly for me is that the default localhost
>> SocketPermission is checked before a more lenient SocketPermission. In theory,
>> one should be able to introspect SocketPermission instances and determine that
>> one may be automatically implied by the other so can be skipped, possibly saving
>> a lookup. Chris
>>
>> Peter Firmstone wrote:
>>     
>>> A big problem with the current implementation is SocketPermission blocks
>>> other permission checks from proceeding.
>>>       
>
>
>   


Mime
View raw message