You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@river.apache.org by Niclas Hedhman <ni...@hedhman.org> on 2008/10/12 18:44:14 UTC
Security problems...
I am getting the exception below when my testcases tries to run
against a Transient Reggie using JERI (well, same result with JRMP),
that I have started.
I suspect that this related to the jsk-policy.jar not being in the
lib/ext. But I need this to work without modifying the JVM
installations... What choices do I have?
Cheers
Niclas
INFO: exception occurred during unicast discovery to
f053112108.adsl.alicedsl.de:55413 with constraints
InvocationConstraints[reqs: {}, prefs: {}]
com.sun.jini.discovery.DiscoveryProtocolException
at com.sun.jini.discovery.DiscoveryV1.doUnicastDiscovery(DiscoveryV1.java:419)
at net.jini.discovery.LookupDiscovery$13.run(LookupDiscovery.java:3327)
at com.sun.jini.start.AggregatePolicyProvider$6.run(AggregatePolicyProvider.java:527)
at java.security.AccessController.doPrivileged(Native Method)
at net.jini.discovery.LookupDiscovery.doUnicastDiscovery(LookupDiscovery.java:3324)
at net.jini.discovery.LookupDiscovery.doUnicastDiscovery(LookupDiscovery.java:3355)
at net.jini.discovery.LookupDiscovery.access$3900(LookupDiscovery.java:696)
at net.jini.discovery.LookupDiscovery$UnicastDiscoveryTask.run(LookupDiscovery.java:1744)
at com.sun.jini.thread.TaskManager$TaskThread.run(TaskManager.java:331)
Caused by: java.lang.SecurityException: attempt to add a Permission to
a readonly Permissions object
at java.security.Permissions.add(Permissions.java:109)
at sun.rmi.server.LoaderHandler.getLoaderAccessControlContext(LoaderHandler.java:981)
at sun.rmi.server.LoaderHandler.lookupLoader(LoaderHandler.java:857)
at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:381)
at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:165)
at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:620)
at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:247)
at net.jini.loader.ClassLoading.loadClass(ClassLoading.java:138)
at net.jini.io.MarshalInputStream.resolveClass(MarshalInputStream.java:296)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1544)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1466)
at java.io.ObjectInputStream.readProxyDesc(ObjectInputStream.java:1508)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1463)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1699)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1908)
at java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.java:479)
at com.sun.jini.reggie.RegistrarProxy.readObject(RegistrarProxy.java:269)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:946)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1809)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
at net.jini.io.MarshalledInstance.get(MarshalledInstance.java:358)
at com.sun.jini.discovery.DiscoveryV1.doUnicastDiscovery(DiscoveryV1.java:397)
... 8 more
Re: Security problems...
Posted by Mark Brouwer <ma...@marbro.org>.
Jukka Zitting wrote:
> Hi,
>
> On Sun, Oct 12, 2008 at 9:59 PM, Mark Brouwer <ma...@marbro.org> wrote:
>> B.T.W. Niclas lately most of your emails had to be accepted by the
>> moderators, so I think you should register some additional email addresses
>> with the mailing lists.
>
> When accepting a moderation request, you can "reply all" to make
> future messages from that sender address automatically pass
> moderation.
Thanks, forgot about that one.
--
Mark
Re: Security problems...
Posted by Niclas Hedhman <ni...@hedhman.org>.
Jukka,
I just posted a question about this to infrastructure-dev. It looks
like it is a Sender: vs From: issue. My subscription mail address
(niclas@hedhman.org) is in the FROM: header, whereas the SENDER:
header is set to the GMail account address (hedhman@gmail.com)... Is
ezmlm actually doing the right thing??
Cheers
Niclas
On Mon, Oct 13, 2008 at 4:36 AM, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> On Sun, Oct 12, 2008 at 9:59 PM, Mark Brouwer <ma...@marbro.org> wrote:
>> B.T.W. Niclas lately most of your emails had to be accepted by the
>> moderators, so I think you should register some additional email addresses
>> with the mailing lists.
>
> When accepting a moderation request, you can "reply all" to make
> future messages from that sender address automatically pass
> moderation.
>
> BR,
>
> Jukka Zitting
>
Re: Security problems...
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Sun, Oct 12, 2008 at 9:59 PM, Mark Brouwer <ma...@marbro.org> wrote:
> B.T.W. Niclas lately most of your emails had to be accepted by the
> moderators, so I think you should register some additional email addresses
> with the mailing lists.
When accepting a moderation request, you can "reply all" to make
future messages from that sender address automatically pass
moderation.
BR,
Jukka Zitting
Re: Security problems...
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Mon, Oct 13, 2008 at 3:59 AM, Mark Brouwer <ma...@marbro.org> wrote:
> Hi Niclas,
>
> Niclas Hedhman wrote:
>>
>> I am getting the exception below when my testcases tries to run
>> against a Transient Reggie using JERI (well, same result with JRMP),
>> that I have started.
>>
>> I suspect that this related to the jsk-policy.jar not being in the
>> lib/ext. But I need this to work without modifying the JVM
>> installations... What choices do I have?
>
> In case you can't install the jsk-policy.jar in the lib/ext directory this
> thread from jini-users might be helpful for you.
>
> http://archives.java.sun.com/cgi-bin/wa?A2=ind0304&L=JINI-USERS&P=R6594
Thanks for the link... Tried it, but it doesn't help. I also tried on
my local system with the jsk-policy in lib/ext and same problem. Do
you know any other bit missing that could result in this Exception?
TIA
Niclas Hedhman
Re: Security problems...
Posted by Mark Brouwer <ma...@marbro.org>.
Hi Niclas,
Niclas Hedhman wrote:
> I am getting the exception below when my testcases tries to run
> against a Transient Reggie using JERI (well, same result with JRMP),
> that I have started.
>
> I suspect that this related to the jsk-policy.jar not being in the
> lib/ext. But I need this to work without modifying the JVM
> installations... What choices do I have?
In case you can't install the jsk-policy.jar in the lib/ext directory
this thread from jini-users might be helpful for you.
http://archives.java.sun.com/cgi-bin/wa?A2=ind0304&L=JINI-USERS&P=R6594
B.T.W. Niclas lately most of your emails had to be accepted by the
moderators, so I think you should register some additional email
addresses with the mailing lists.
Regards,
--
Mark
Re: Security problems...
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thu, Oct 16, 2008 at 5:00 PM, Peter Jones <pe...@sun.com> wrote:
> That explains it. (And the Java 6 API change was a red herring,
> although I'm glad to have learned about it anyway.) Your test Policy
> implementation's getPermissions method must return a new permission
> collection on every invocation, per the spec contract previously
> discussed, so that each caller's mutations are isolated. As it is
> above, one caller will add permissions to the collection and use it to
> create a protection domain, which will cause it to be set read-only,
> and then a later caller will try to add permissions to the collection,
> but receiving the same collection as the previous caller, will find it
> to have been set read-only, causing the the exception you reported.
Thanks, and I have now more reasons to be upset with "POJO"/JavaBeans
naming conventions indoctrinating us. "get" at first glance sounds
like a side-effect free operation. Well, well... assumptions are
mother of all fuck-ups.
Cheers
Niclas
Re: Security problems...
Posted by Peter Jones <pe...@sun.com>.
On Thu, Oct 16, 2008 at 11:44:59AM +0200, Niclas Hedhman wrote:
> On Wed, Oct 15, 2008 at 8:16 PM, Peter Jones <pe...@sun.com> wrote:
>> Interesting exception trace. Do you know the actual class of the
>> java.security.Policy in effect in this JVM?
>
> Yes, I do;
> This is all to set up my automated tests (which I think is River's
> weakest point at the moment), so it is a simple inner class. It looks
> like this;
>
> // test initialization
> if( System.getSecurityManager() == null )
> {
> Policy allPolicy = new TestPolicyAllPermissions();
> Policy.setPolicy( allPolicy );
> System.setSecurityManager( new SecurityManager() );
> }
>
> // test policy
> private static class TestPolicyAllPermissions extends Policy
> {
> private Permissions permissions;
>
> private TestPolicyAllPermissions()
> {
> permissions = new Permissions();
> permissions.add( new AllPermission() );
> }
>
> public PermissionCollection getPermissions( CodeSource codeSource )
> {
> return permissions;
> }
That explains it. (And the Java 6 API change was a red herring,
although I'm glad to have learned about it anyway.) Your test Policy
implementation's getPermissions method must return a new permission
collection on every invocation, per the spec contract previously
discussed, so that each caller's mutations are isolated. As it is
above, one caller will add permissions to the collection and use it to
create a protection domain, which will cause it to be set read-only,
and then a later caller will try to add permissions to the collection,
but receiving the same collection as the previous caller, will find it
to have been set read-only, causing the the exception you reported.
-- Peter
Re: Security problems...
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wed, Oct 15, 2008 at 8:16 PM, Peter Jones <pe...@sun.com> wrote:
> Interesting exception trace. Do you know the actual class of the
> java.security.Policy in effect in this JVM?
Yes, I do;
This is all to set up my automated tests (which I think is River's
weakest point at the moment), so it is a simple inner class. It looks
like this;
// test initialization
if( System.getSecurityManager() == null )
{
Policy allPolicy = new TestPolicyAllPermissions();
Policy.setPolicy( allPolicy );
System.setSecurityManager( new SecurityManager() );
}
// test policy
private static class TestPolicyAllPermissions extends Policy
{
private Permissions permissions;
private TestPolicyAllPermissions()
{
permissions = new Permissions();
permissions.add( new AllPermission() );
}
public PermissionCollection getPermissions( CodeSource codeSource )
{
return permissions;
}
public void refresh()
{
}
}
Thanks for the elaborate thought on the subject. I have no further
information on the subject, as I have not worked on this since I
posted this last time.
One piece that might be of importance is that the Security Policy
provided to the NonActivatableServiceDescriptor constructor (system
under test), is a standard policy file, but created on the fly. At the
moment it just sets the default grant to AllPermissions.
Cheers
Niclas
Re: Security problems...
Posted by Peter Jones <pe...@sun.com>.
Interesting exception trace. Do you know the actual class of the
java.security.Policy in effect in this JVM?
The RMIClassLoader implementation (the default implementation as well
as net.jini.loader.pref.PreferredClassProvider) assumes that it can
add arbitrary permissions to the PermissionCollection returned by an
invocation of getPermissions(CodeSource) on the Policy in effect--
i.e. that this PermissionCollection will not have been set read-only.
With J2SE 5.0 and earlier, that was a reasonable assumption, as the
@return specification for that method, which was abstract in
java.security.Policy, included this contract:
The returned set of permissions must be a new mutable instance and
it must support heterogeneous Permission types.
But in Java SE 6, the Policy.getPermissions(CodeSource) spec was
changed to allow the implementation to "not support" the operation, in
which case it is specified to return a singleton (?) read-only empty
PermissionCollection-- and the method was made non-abstract, with the
default implementation carrying out this "not supported" mode. A
Policy that implements this mode breaks the above-mentioned assumption
in the RMIClassLoader implementation and would cause the exception in
the trace below. I was not previously aware of this change in Java 6,
and I must say that I find it rather surprising (the breaking of the
mutability contract).
The Sun JDK's default Policy implementation
(sun.security.provider.PolicyFile) still implements (now overrides)
getPermissions(CodeSource) to return a new mutable collection as
before, so with the default policy, or another that wraps it, this
problem would not be noticed-- it would only seem to be noticed when
using a Policy implementation written for the Java 6 API.
-- Peter
On Mon, Oct 13, 2008 at 12:44:14AM +0800, Niclas Hedhman wrote:
> I am getting the exception below when my testcases tries to run
> against a Transient Reggie using JERI (well, same result with JRMP),
> that I have started.
>
> I suspect that this related to the jsk-policy.jar not being in the
> lib/ext. But I need this to work without modifying the JVM
> installations... What choices do I have?
>
> Cheers
> Niclas
>
> INFO: exception occurred during unicast discovery to
> f053112108.adsl.alicedsl.de:55413 with constraints
> InvocationConstraints[reqs: {}, prefs: {}]
> com.sun.jini.discovery.DiscoveryProtocolException
> at com.sun.jini.discovery.DiscoveryV1.doUnicastDiscovery(DiscoveryV1.java:419)
> at net.jini.discovery.LookupDiscovery$13.run(LookupDiscovery.java:3327)
> at com.sun.jini.start.AggregatePolicyProvider$6.run(AggregatePolicyProvider.java:527)
> at java.security.AccessController.doPrivileged(Native Method)
> at net.jini.discovery.LookupDiscovery.doUnicastDiscovery(LookupDiscovery.java:3324)
> at net.jini.discovery.LookupDiscovery.doUnicastDiscovery(LookupDiscovery.java:3355)
> at net.jini.discovery.LookupDiscovery.access$3900(LookupDiscovery.java:696)
> at net.jini.discovery.LookupDiscovery$UnicastDiscoveryTask.run(LookupDiscovery.java:1744)
> at com.sun.jini.thread.TaskManager$TaskThread.run(TaskManager.java:331)
> Caused by: java.lang.SecurityException: attempt to add a Permission to
> a readonly Permissions object
> at java.security.Permissions.add(Permissions.java:109)
> at sun.rmi.server.LoaderHandler.getLoaderAccessControlContext(LoaderHandler.java:981)
> at sun.rmi.server.LoaderHandler.lookupLoader(LoaderHandler.java:857)
> at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:381)
> at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:165)
> at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:620)
> at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:247)
> at net.jini.loader.ClassLoading.loadClass(ClassLoading.java:138)
> at net.jini.io.MarshalInputStream.resolveClass(MarshalInputStream.java:296)
> at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1544)
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1466)
> at java.io.ObjectInputStream.readProxyDesc(ObjectInputStream.java:1508)
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1463)
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1699)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
> at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1908)
> at java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.java:479)
> at com.sun.jini.reggie.RegistrarProxy.readObject(RegistrarProxy.java:269)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:946)
> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1809)
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
> at net.jini.io.MarshalledInstance.get(MarshalledInstance.java:358)
> at com.sun.jini.discovery.DiscoveryV1.doUnicastDiscovery(DiscoveryV1.java:397)
> ... 8 more