Concurrent Policy provider

Peter Firmstone peter.firmstone at zeus.net.au
Fri Jul 11 03:00:18 UTC 2014 

Would there be interest in using a Policy provider and SecurityManager 
designed for concurrency in Java 9?

Some of the issues experienced and solutions are mentioned below.

http://svn.apache.org/viewvc/river/jtsk/skunk/qa_refactor/trunk/src/org/apache/river/api/security/

Regards,

Peter.

-------- Original Message --------
Subject: 	Concurrency-interest Digest, Vol 113, Issue 45
Date: 	Mon, 30 Jun 2014 12:00:01 -0400
From: 	concurrency-interest-request at cs.oswego.edu
Reply-To: 	concurrency-interest at cs.oswego.edu
To: 	concurrency-interest at cs.oswego.edu



Send Concurrency-interest mailing list submissions to
	concurrency-interest at cs.oswego.edu

To subscribe or unsubscribe via the World Wide Web, visit
	http://cs.oswego.edu/mailman/listinfo/concurrency-interest
or, via email, send a message with subject or body 'help' to
	concurrency-interest-request at cs.oswego.edu

You can reach the person managing the list at
	concurrency-interest-owner at cs.oswego.edu

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Concurrency-interest digest..."


Today's Topics:

    1. Re: ThreadLocalRandom clinit troubles (Peter Firmstone)
    2. Re: ThreadLocalRandom clinit troubles (Alan Bateman)


----------------------------------------------------------------------

Message: 1
Date: Mon, 30 Jun 2014 20:02:30 +1000
From: Peter Firmstone<peter.firmstone at zeus.net.au>
To: Peter Levart<peter.levart at gmail.com>
Cc: concurrency-interest at cs.oswego.edu
Subject: Re: [concurrency-interest] ThreadLocalRandom clinit troubles
Message-ID:<53B135B6.1030105 at zeus.net.au>
Content-Type: text/plain; charset=UTF-8; format=flowed

Hi Peter,

There are a number of bottlenecks throughout the security
infrastructure, we have reimplemented it as follows to avoid them and
have also addressed some long standing issues:

SecurityManager - cache previously checked AccessControlContext's
(using a cache structure based on Cliff Click's non blocking hash map
and Doug Lee's concurrent skip list set), to avoid repeately calling the
policy provider (for example, you have numerous tasks in an
ExecutorService and each has an identical AccessControlContext and all
tasks cause a SocketPermission check).

Policy provider - replaced the built in Java policy provider.  The built
in Java Policy provider will hold a lock while making DNS calls,
bringing all permission checks to a grinding halt.  It will also hold
locks while accessing the file system.

To avoid making DNS calls we've implemented our own policy provider,
originated from Apache Harmony, but modified to use non blocking
immutability.  It creates PermissionCollection's on demand, they're not
shared among threads and are ordered in the most favourable order for a
fast result.  It also supports undocumented Java file policy provider
functionality.  Because Permission objects are immutable but lazily
initialized, we call getActions() to ensure their state is completely
initialized prior to publication.

The policy provider uses a strictly RFC 3986 compliant immutable URI
class, it performs bit shift operations on ASCII strings during
normalisation and is used by the policy provider to avoid making DNS
calls when checking CodeBase policy file permissions.

As a result, the cost of the security infrastructure is less than 1% of
CPU load during stress tests.

This is part of the Apache River project, JERI (Jini Extensible Remote
Invocation) performs remote method invocations as tasks running in a
system threadpool, each task executes concurrently on any exported service.

SecureClassLoader uses CodeSource's as keys in a Map, CodeSource uses
URL in equals() and hashCode(), so we also have a RFC3986 compliant
URLClassLoader to avoid making unnecessary DNS calls in SecureClassLoader.

Rather than rely on an external untrusted DNS to determine the identity
of CodeSource's, we use RFC 3986 compliant normalisation, without making
DNS calls.  URL's still make DNS calls when retrieving a URL.  The
difference is, two different host names that previously resolved to an
identical IP address will no longer be equal, but now we can use dynamic
dns addresses and fail over replication for domain names that use a
range of IP addresses to answer for one domain address.  Standard Java
SecureClassLoader behaviour can be had by setting a system property

This also reduces or avoids calls to the built in java NameServiceProvider.

If this code was in the JVM libraries, we wouldn't need it in our project.

This code is freely available.

Regards,

Peter.

On 29/06/2014 7:29 PM, Peter Levart wrote:
>
>  On 06/29/2014 03:53 AM, Peter Firmstone wrote:
>>
>>  It does look like a good solution.
>>
>>  You might wonder why we still need a custom SecurityManager?
>>
>>  Concurrency.
>>
>>  The ageing java security infrastructure is a huge bottleneck for
>>  multithreaded code.
>>
>>  Regards,
>>
>>  Peter.
>>
>
>  Hi Peter,
>
>  If you could identify the most critical bottleneck(s) of default
>  SecurityManager, there might be a way to fix them...
>
>  Regards, Peter
>
>>
>>
>>
>>
>>
>>
>>
>>  >  Message: 1
>>  >  Date: Thu, 26 Jun 2014 19:10:22 -0400
>>  >  From: Doug Lea<dl at cs.oswego.edu<mailto:dl at cs.oswego.edu>>
>>  >  To: Peter Levart<peter.levart at gmail.com
>>  <mailto:peter.levart at gmail.com>>
>>  >  Cc: core-libs-dev<core-libs-dev at openjdk.java.net
>>  <mailto:core-libs-dev at openjdk.java.net>>,    OpenJDK
>>  >  <security-dev at openjdk.java.net
>>  <mailto:security-dev at openjdk.java.net>>,    concurrency-interest
>>  >  <concurrency-interest at cs.oswego.edu
>>  <mailto:concurrency-interest at cs.oswego.edu>>
>>  >  Subject: Re: [concurrency-interest] ThreadLocalRandom clinit troubles
>>  >  Message-ID:<53ACA85E.2030407 at cs.oswego.edu
>>  <mailto:53ACA85E.2030407 at cs.oswego.edu>>
>>  >  Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>  >
>>  >
>>  >  Peter: Thanks very much for attacking the shocking impact/complexity
>>  >  of getting a few seed bits.
>>  >
>>  >  On 06/25/2014 01:41 PM, Peter Levart wrote:
>>  >  >
>>  >  >  Peeking around in the sun.security.provider package, I found there
>>  >  >  already is a minimal internal infrastructure for obtaining random
>>  >  >  seed. It's encapsulated in package-private abstract class
>>  >  >  sun.security.provider.SeedGenerator with 4 implementations. It turns
>>  >  >  out that, besides Java-only fall-back implementation called
>>  >  >  ThreadedSeedGenerator and generic URLSeedGenerator, there are
>>  also two
>>  >  >  implementations of NativeSeedGenerator (one for UNIX-es which is
>>  just
>>  >  >  an extension of URLSeedGenerator and the other for Windows which
>>  uses
>>  >  >  MS CryptoAPI). I made a few tweaks that allow this
>>  sub-infrastructure
>>  >  >  to be used directly in ThreadLocalRandom and SplittableRandom:
>>  >  >
>>  >  >
>>  http://cr.openjdk.java.net/~plevart/jdk9-dev/TLR_SR_SeedGenerator/webrev.01/
>>  <http://cr.openjdk.java.net/%7Eplevart/jdk9-dev/TLR_SR_SeedGenerator/webrev.01/>
>>
>>  >  >
>>  >
>>  >  This seems to be the best idea yet, assuming that people are OK
>>  >  with the changes to sun.security.provider.SeedGenerator and
>>  >  NativeSeedGenerator.java
>>  >
>>  >  -Doug
>>
>>
>>
>>  _______________________________________________
>>  Concurrency-interest mailing list
>>  Concurrency-interest at cs.oswego.edu
>>  http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>



------------------------------

Message: 2
Date: Mon, 30 Jun 2014 13:53:38 +0100
From: Alan Bateman<Alan.Bateman at oracle.com>
To: Peter Firmstone<peter.firmstone at zeus.net.au>
Cc: concurrency-interest at cs.oswego.edu
Subject: Re: [concurrency-interest] ThreadLocalRandom clinit troubles
Message-ID:<53B15DD2.8020200 at oracle.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 30/06/2014 11:02, Peter Firmstone wrote:
>  Hi Peter,
>
>  There are a number of bottlenecks throughout the security
>  infrastructure, we have reimplemented it as follows to avoid them and
>  have also addressed some long standing issues:
>
>
>  If this code was in the JVM libraries, we wouldn't need it in our
>  project.
>
Have you considered bring some of these patches to OpenJDK?

On RFC 3986 (you mentioned this a number of times) then there were
previous attempts bring URI up to this, unfortunately had to be backed
out due to compatibility issues and other breakage. It's definitely
something that needs to be looked at again.

-Alan



------------------------------

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest at cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


End of Concurrency-interest Digest, Vol 113, Issue 45
*****************************************************

More information about the security-dev mailing list