river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jgr...@simulexinc.com
Subject Re: light refactoring
Date Fri, 31 Dec 2010 04:19:36 GMT
100% agree; documentation would help, as would warning suppression.

jamesG

-----Original Message-----
From: "Patricia Shanahan" <pats@acm.org>
Sent: Thursday, December 30, 2010 9:55am
To: river-dev@incubator.apache.org
Subject: Re: light refactoring

If it is not already planned, I suggest adding a comment summarizing 
this information. Also, in anything Java 5 or later, the method can be 
annotated to suppress any warning about the unused private method, so we 
can still aim for warning-free code.

Patricia


On 12/30/2010 5:56 AM, Brian Murphy wrote:
> On Wed, Dec 29, 2010 at 1:37 AM,<jgrahn@simulexinc.com>  wrote:
>
> 3) Several of the "Constrainable" classes have the private method
>> "getProxyTrustIterator" which is never used.   Is this safe to remove?
>
>
> No, this will break outrigger with respect to remote security.
>
> The getProxyTrustIterator method is called reflectively by the
> infrastructure, and is necessary for verifying trust in the proxies
> (both dynamic and non-dynamic) that a client might receive.
> Therefore, that method is somewhat fundamental to the
> extensions that were made to the Java security model to
> support network security in the face of remote method
> invocations and downloaded code. From the specification of
> the net.jini.security.proxytrust.ProxyTrustVerifier.isTrusted
> method:
>
> [snip]
>       * A verifier is obtained from a candidate object as follows.
>       *<ul>
>       *<li>
>       * If either the candidate object's class has a non-<code>static</code>
>       * member method with signature:
>       *<pre>ProxyTrustIterator getProxyTrustIterator();</pre>
>       * or the candidate object is an instance of a dynamically generated
>       * {@link Proxy} class and the contained invocation handler's class has
>       * such a member method, then the<code>getProxyTrustIterator</code>
>       * method is called (on the candidate object or its invocation handler).
>       * For each object produced by the {@link ProxyTrustIterator#next next}
>       * method of the returned iterator, the following substeps are used,
> until
>       * either a verifier is obtained or the iteration terminates. If no
>       * verifier can be obtained from any object produced by the iterator,
>       * then there is no verifier for the candidate object. For any given
>       * object produced by the iterator, if a verifier cannot be obtained
> from
>       * the object but an intermediate operation involved in attempting to
>       * obtain a verifier throws a<code>RemoteException</code>, that
>       * exception is passed to the {@link ProxyTrustIterator#setException
>       * setException} method of the iterator, and the iteration continues.
>       *<p>
>       * The<code>getProxyTrustIterator</code>  method and the
>       *<code>ProxyTrustIterator</code>  methods are all invoked in a
>       * restricted security context. If the specified trust verifier
>       * context contains an {@link UntrustedObjectSecurityContext} instance,
>       * then the security context returned by its
>       * {@link UntrustedObjectSecurityContext#getContext getContext} method
>       * is used. Otherwise, the security context used is equivalent to
>       * the current security context (as returned by
>       * {@link net.jini.security.Security#getContext Security.getContext})
> with
>       * an additional protection domain combined into the access control
>       * context that contains an empty {@link java.security.CodeSource}
>       * (<code>null</code>  location and certificates),
>       *<code>null</code>  permissions,<code>null</code>  class
loader, and
>       *<code>null</code>  principals.
> [snip]
>
> I hope this helps,
> Brian
>




Mime
View raw message