river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: Implications for Security Checks - SocketPermission, URL and DNS lookups
Date Tue, 13 Dec 2011 21:00:45 GMT
That's exactly what I'm thinking, order SocketPermissions first, implemented using a comparator,
add to a new SocketPermissionCollection in order, then perform the security check.

The comparator can perform the introspection to customise the order for every securiity check,
eg so that wild cards are checked first, avoiding the dns lookup in most cases.

That way comparators encapsulate the introspection and we can keep the policy implementation

In my concurrent policy, while localhost is being resolved for a ProtectionDomain, other threads
are blocked from performing any SocketPermission checks on that ProtectionDomain, if that
PD represents library code shared throughout your app, that too can bring it to a standstill.



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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message