You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Peter <ji...@zeus.net.au> on 2012/01/10 07:24:06 UTC
SVN Merge
The new security manager and policies are almost ready to merge back into trunk.
Any svn merge tips would be much appreciated.
First, I'd like to move some policy implementation classes that are at present public in org.apache.river.*, into package private net.jini.* namespaces, to reduce the public api.
Not all of the code will be included, classes, like ConcurrentPermissions (and all policy cache associated classes), even though far better than Permissions, will be discarded, as recent developments (eliminating policy cache) have made them redundant.
DelegatePermission is still there, designed to work with delegate wrapper classes that encapsulate sockets and and file handles, to enable removal of temporarily granted permissions.
Example: A downloaded proxy is granted a SocketPermission to contact its server, if during deserialisation, the proxy modifies some public static fields (java.xml.* vulnerabilities ring a bell?) by replacing some platform classes with its own, it leaves some of its own proxy code on the stack context. The proxy after being downloaded is found to be untrusted and discarded.
Every time the object the proxy has injected into the platform is accessed, it steals information and sends it back to its originating host.
If a DelegatePermission(SocketPermission p) is granted instead, the proxy recieves a socket that denies access when the permission is revoked, when trust can't be verified.
The proxy could still perform a denial of service, by causing an out of memory error during deserialisation.
DelegatePermission can also be used to grant temporary or limited access to Principals, eg after downloading 1GB, downloads are revoked and regranted at the next monthly cycle, something sililar could be used to limit writes to the file system.
Obviously you'll need to buffer the input or output streams, to balance how often checks are performed, that is, if you choose to utilise it.
A DelegateSocketFactory that can be used to encapsulate existing SocketFactory's will be released at a later date to enable DelegatePermission controlled streams and channels. Note any ProtectionDomains with SocketPermission will still have access to the same channel.
DelegatePermission is intended to be a dynamically or runtime granted Permission.
To function it requires a DelegateSecurityManager, each stack context domain must have permission either for the DelegatePermission or it's representative Permission.
This was one motivation for a securitymanager cache, it needed to be as fast as possible and non blocking, unlike policy cache.
Using delegates is of course optional.
The other thing I was toying with was using deny as well as grant in policy files:
Where denials would be checked first by the policy prior to checking grants:
So you could deny a proxy access to the local network, whilst granting it access to the entire internet, with two simple policy statements.
Or you could allow access to a directory, but deny access to a user policy file contained in that directory, for principal based grants.
The syntax would be identical to a grant statement in policy files, except deny replaces grant.
But then I realised despite the advantages, it adds complexity, because the deny statement could have unintended scope narrowing / widening consequences and Permissions like SocketPermission don't work as well as intended, it would be simpler to dynamically grant Permissions on an as needed basis.
So any last remaining traces of deny must be removed.
Instead of using deny in policy grants, I figure that proxy's can optionally include permissions.perms files under META-INF in their jar files as a hint to clients. By using the least priviledge model and limiting the GrantPermissions given to Principals administrators can limit Permissions users can grant to proxy's.
The proxy developers would need to be aware they might not be granted all the permissions they'd like and offer reduced functionality by catching SecurityException.
Regards,
Peter.
Re: SVN Merge
Posted by Peter Firmstone <ji...@zeus.net.au>.
Ok, ok, how about we cross that bridge when we come to it.
Anyone reviewing the code for me, so we don't have to?
Simon IJskes - QCG wrote:
> On 11-01-12 09:26, Dan Creswell wrote:
>> "once we publish them we're stuck with them"
>>
>> Why? Presumably we're stuck with them in the same way that Intel are
>> stuck with continuing to support a huge legacy?
>>
>> Of course I don't subscribe to such an attitude - if they're broken,
>> we fix them. Even internet API's behave this way in spite of all the
>> good REST'ian things said about preserving URL's etc because nothing
>> else is practical. We routinely see fork'ing of internet API's or
>> versioning where an old API remains but in a run-down, no longer
>> supported state whilst development goes on elsewhere. That's the
>> equivalent of leaving an API in an old version of the River kit and
>> replacing it in a newer version.
>>
>> Nothing is perfect at release, there's nothing wrong with trying to be
>> as right as possible but there are limits and we need to recognise
>> that rather than obsess over achieving the impossible.
>>
>> Dan.
>
> +10!
>
>
Re: SVN Merge
Posted by Simon IJskes - QCG <si...@qcg.nl>.
On 11-01-12 09:26, Dan Creswell wrote:
> "once we publish them we're stuck with them"
>
> Why? Presumably we're stuck with them in the same way that Intel are
> stuck with continuing to support a huge legacy?
>
> Of course I don't subscribe to such an attitude - if they're broken,
> we fix them. Even internet API's behave this way in spite of all the
> good REST'ian things said about preserving URL's etc because nothing
> else is practical. We routinely see fork'ing of internet API's or
> versioning where an old API remains but in a run-down, no longer
> supported state whilst development goes on elsewhere. That's the
> equivalent of leaving an API in an old version of the River kit and
> replacing it in a newer version.
>
> Nothing is perfect at release, there's nothing wrong with trying to be
> as right as possible but there are limits and we need to recognise
> that rather than obsess over achieving the impossible.
>
> Dan.
+10!
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: SVN Merge
Posted by Dan Creswell <da...@gmail.com>.
"once we publish them we're stuck with them"
Why? Presumably we're stuck with them in the same way that Intel are
stuck with continuing to support a huge legacy?
Of course I don't subscribe to such an attitude - if they're broken,
we fix them. Even internet API's behave this way in spite of all the
good REST'ian things said about preserving URL's etc because nothing
else is practical. We routinely see fork'ing of internet API's or
versioning where an old API remains but in a run-down, no longer
supported state whilst development goes on elsewhere. That's the
equivalent of leaving an API in an old version of the River kit and
replacing it in a newer version.
Nothing is perfect at release, there's nothing wrong with trying to be
as right as possible but there are limits and we need to recognise
that rather than obsess over achieving the impossible.
Dan.
On 11 January 2012 01:26, Peter Firmstone <ji...@zeus.net.au> wrote:
> Having a look at any new interfaces, once we publish them we're stuck with
> them, so any thoughts or questions (Do I need to improved docs etc) would be
> appreciated.
>
> Regards,
>
> Peter.
>
>
> Tom Hobbs wrote:
>>
>> I can try and find some time for you. Let me know what you need and I'll
>> do my best.
>>
>> Sent via mobile device, please forgive typos and spacing errors.
>>
>> On 10 Jan 2012 12:17, "Peter Firmstone" <ji...@zeus.net.au> wrote:
>>
>>
>>>
>>> Tom & Dan, thanks for the support, we're probably looking at a dry run by
>>> the weekend, right now I'm running the tests again, this run is expected
>>> to
>>> pass, I'm just checking for any regressions (same code in svn). I'll
>>> clean
>>> out all the redundant code, followed by some refactoring to move new
>>> public
>>> utility classes into package private where possible.
>>>
>>> I've you've got some time, I could use a hand to go over the new code to
>>> tidy up any loose ends, make sure any new public api looks right before
>>> we
>>> merge, so we can release quickly, once the merge is complete.
>>>
>>> At this point, the code's only been tested on sparc.
>>>
>>> Cheers,
>>>
>>> Peter.
>>>
>>> Dan Creswell wrote:
>>>
>>>
>>>>
>>>> Agreed, remember --dry-run will give you a preview of what's to come
>>>> in a merge if you have concerns...
>>>>
>>>> On 10 January 2012 10:08, Tom Hobbs <tv...@googlemail.com> wrote:
>>>>
>>>>
>>>>
>>>>>
>>>>> Let SVN do the merge, your changes might be extensive but I doubt there
>>>>> has
>>>>> been much movement in those files since you checked them out. So the
>>>>> merge
>>>>> will probably be more of a replace.
>>>>>
>>>>> I'm hoping to get some coding done in the next few weeks - at last! So
>>>>> we
>>>>> might have enough changes soon for a release.
>>>>>
>>>>> Keep up the good work, Peter.
>>>>>
>>>>> Sent via mobile device, please forgive typos and spacing errors.
>>>>>
>>>>> On 10 Jan 2012 06:20, "Peter" <ji...@zeus.net.au> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> The new security manager and policies are almost ready to merge back
>>>>>> into
>>>>>> trunk.
>>>>>>
>>>>>> Any svn merge tips would be much appreciated.
>>>>>>
>>>>>> First, I'd like to move some policy implementation classes that are at
>>>>>> present public in org.apache.river.*, into package private net.jini.*
>>>>>> namespaces, to reduce the public api.
>>>>>>
>>>>>> Not all of the code will be included, classes, like
>>>>>> ConcurrentPermissions
>>>>>> (and all policy cache associated classes), even though far better than
>>>>>> Permissions, will be discarded, as recent developments (eliminating
>>>>>> policy
>>>>>> cache) have made them redundant.
>>>>>>
>>>>>> DelegatePermission is still there, designed to work with delegate
>>>>>> wrapper
>>>>>> classes that encapsulate sockets and and file handles, to enable
>>>>>> removal of
>>>>>> temporarily granted permissions.
>>>>>>
>>>>>> Example: A downloaded proxy is granted a SocketPermission to contact
>>>>>> its
>>>>>> server, if during deserialisation, the proxy modifies some public
>>>>>> static
>>>>>> fields (java.xml.* vulnerabilities ring a bell?) by replacing some
>>>>>> platform
>>>>>> classes with its own, it leaves some of its own proxy code on the
>>>>>> stack
>>>>>> context. The proxy after being downloaded is found to be untrusted
>>>>>> and
>>>>>> discarded.
>>>>>>
>>>>>> Every time the object the proxy has injected into the platform is
>>>>>> accessed, it steals information and sends it back to its originating
>>>>>> host.
>>>>>>
>>>>>> If a DelegatePermission(**SocketPermission p) is granted instead, the
>>>>>> proxy
>>>>>> recieves a socket that denies access when the permission is revoked,
>>>>>> when
>>>>>> trust can't be verified.
>>>>>>
>>>>>> The proxy could still perform a denial of service, by causing an out
>>>>>> of
>>>>>> memory error during deserialisation.
>>>>>>
>>>>>> DelegatePermission can also be used to grant temporary or limited
>>>>>> access
>>>>>> to Principals, eg after downloading 1GB, downloads are revoked and
>>>>>> regranted at the next monthly cycle, something sililar could be used
>>>>>> to
>>>>>> limit writes to the file system.
>>>>>>
>>>>>> Obviously you'll need to buffer the input or output streams, to
>>>>>> balance
>>>>>> how often checks are performed, that is, if you choose to utilise it.
>>>>>>
>>>>>> A DelegateSocketFactory that can be used to encapsulate existing
>>>>>> SocketFactory's will be released at a later date to enable
>>>>>> DelegatePermission controlled streams and channels. Note any
>>>>>> ProtectionDomains with SocketPermission will still have access to the
>>>>>> same
>>>>>> channel.
>>>>>>
>>>>>> DelegatePermission is intended to be a dynamically or runtime granted
>>>>>> Permission.
>>>>>>
>>>>>> To function it requires a DelegateSecurityManager, each stack context
>>>>>> domain must have permission either for the DelegatePermission or it's
>>>>>> representative Permission.
>>>>>>
>>>>>> This was one motivation for a securitymanager cache, it needed to be
>>>>>> as
>>>>>> fast as possible and non blocking, unlike policy cache.
>>>>>>
>>>>>> Using delegates is of course optional.
>>>>>>
>>>>>> The other thing I was toying with was using deny as well as grant in
>>>>>> policy files:
>>>>>>
>>>>>> Where denials would be checked first by the policy prior to checking
>>>>>> grants:
>>>>>>
>>>>>> So you could deny a proxy access to the local network, whilst granting
>>>>>> it
>>>>>> access to the entire internet, with two simple policy statements.
>>>>>>
>>>>>> Or you could allow access to a directory, but deny access to a user
>>>>>> policy
>>>>>> file contained in that directory, for principal based grants.
>>>>>>
>>>>>> The syntax would be identical to a grant statement in policy files,
>>>>>> except
>>>>>> deny replaces grant.
>>>>>>
>>>>>> But then I realised despite the advantages, it adds complexity,
>>>>>> because
>>>>>> the deny statement could have unintended scope narrowing / widening
>>>>>> consequences and Permissions like SocketPermission don't work as well
>>>>>> as
>>>>>> intended, it would be simpler to dynamically grant Permissions on an
>>>>>> as
>>>>>> needed basis.
>>>>>>
>>>>>> So any last remaining traces of deny must be removed.
>>>>>>
>>>>>> Instead of using deny in policy grants, I figure that proxy's can
>>>>>> optionally include permissions.perms files under META-INF in their jar
>>>>>> files as a hint to clients. By using the least priviledge model and
>>>>>> limiting the GrantPermissions given to Principals administrators can
>>>>>> limit
>>>>>> Permissions users can grant to proxy's.
>>>>>>
>>>>>> The proxy developers would need to be aware they might not be granted
>>>>>> all
>>>>>> the permissions they'd like and offer reduced functionality by
>>>>>> catching
>>>>>> SecurityException.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Peter.
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
>
Re: SVN Merge
Posted by Peter Firmstone <ji...@zeus.net.au>.
Having a look at any new interfaces, once we publish them we're stuck
with them, so any thoughts or questions (Do I need to improved docs etc)
would be appreciated.
Regards,
Peter.
Tom Hobbs wrote:
> I can try and find some time for you. Let me know what you need and I'll
> do my best.
>
> Sent via mobile device, please forgive typos and spacing errors.
>
> On 10 Jan 2012 12:17, "Peter Firmstone" <ji...@zeus.net.au> wrote:
>
>
>> Tom & Dan, thanks for the support, we're probably looking at a dry run by
>> the weekend, right now I'm running the tests again, this run is expected to
>> pass, I'm just checking for any regressions (same code in svn). I'll clean
>> out all the redundant code, followed by some refactoring to move new public
>> utility classes into package private where possible.
>>
>> I've you've got some time, I could use a hand to go over the new code to
>> tidy up any loose ends, make sure any new public api looks right before we
>> merge, so we can release quickly, once the merge is complete.
>>
>> At this point, the code's only been tested on sparc.
>>
>> Cheers,
>>
>> Peter.
>>
>> Dan Creswell wrote:
>>
>>
>>> Agreed, remember --dry-run will give you a preview of what's to come
>>> in a merge if you have concerns...
>>>
>>> On 10 January 2012 10:08, Tom Hobbs <tv...@googlemail.com> wrote:
>>>
>>>
>>>
>>>> Let SVN do the merge, your changes might be extensive but I doubt there
>>>> has
>>>> been much movement in those files since you checked them out. So the
>>>> merge
>>>> will probably be more of a replace.
>>>>
>>>> I'm hoping to get some coding done in the next few weeks - at last! So we
>>>> might have enough changes soon for a release.
>>>>
>>>> Keep up the good work, Peter.
>>>>
>>>> Sent via mobile device, please forgive typos and spacing errors.
>>>>
>>>> On 10 Jan 2012 06:20, "Peter" <ji...@zeus.net.au> wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> The new security manager and policies are almost ready to merge back
>>>>> into
>>>>> trunk.
>>>>>
>>>>> Any svn merge tips would be much appreciated.
>>>>>
>>>>> First, I'd like to move some policy implementation classes that are at
>>>>> present public in org.apache.river.*, into package private net.jini.*
>>>>> namespaces, to reduce the public api.
>>>>>
>>>>> Not all of the code will be included, classes, like
>>>>> ConcurrentPermissions
>>>>> (and all policy cache associated classes), even though far better than
>>>>> Permissions, will be discarded, as recent developments (eliminating
>>>>> policy
>>>>> cache) have made them redundant.
>>>>>
>>>>> DelegatePermission is still there, designed to work with delegate
>>>>> wrapper
>>>>> classes that encapsulate sockets and and file handles, to enable
>>>>> removal of
>>>>> temporarily granted permissions.
>>>>>
>>>>> Example: A downloaded proxy is granted a SocketPermission to contact its
>>>>> server, if during deserialisation, the proxy modifies some public static
>>>>> fields (java.xml.* vulnerabilities ring a bell?) by replacing some
>>>>> platform
>>>>> classes with its own, it leaves some of its own proxy code on the stack
>>>>> context. The proxy after being downloaded is found to be untrusted and
>>>>> discarded.
>>>>>
>>>>> Every time the object the proxy has injected into the platform is
>>>>> accessed, it steals information and sends it back to its originating
>>>>> host.
>>>>>
>>>>> If a DelegatePermission(**SocketPermission p) is granted instead, the
>>>>> proxy
>>>>> recieves a socket that denies access when the permission is revoked,
>>>>> when
>>>>> trust can't be verified.
>>>>>
>>>>> The proxy could still perform a denial of service, by causing an out of
>>>>> memory error during deserialisation.
>>>>>
>>>>> DelegatePermission can also be used to grant temporary or limited access
>>>>> to Principals, eg after downloading 1GB, downloads are revoked and
>>>>> regranted at the next monthly cycle, something sililar could be used to
>>>>> limit writes to the file system.
>>>>>
>>>>> Obviously you'll need to buffer the input or output streams, to balance
>>>>> how often checks are performed, that is, if you choose to utilise it.
>>>>>
>>>>> A DelegateSocketFactory that can be used to encapsulate existing
>>>>> SocketFactory's will be released at a later date to enable
>>>>> DelegatePermission controlled streams and channels. Note any
>>>>> ProtectionDomains with SocketPermission will still have access to the
>>>>> same
>>>>> channel.
>>>>>
>>>>> DelegatePermission is intended to be a dynamically or runtime granted
>>>>> Permission.
>>>>>
>>>>> To function it requires a DelegateSecurityManager, each stack context
>>>>> domain must have permission either for the DelegatePermission or it's
>>>>> representative Permission.
>>>>>
>>>>> This was one motivation for a securitymanager cache, it needed to be as
>>>>> fast as possible and non blocking, unlike policy cache.
>>>>>
>>>>> Using delegates is of course optional.
>>>>>
>>>>> The other thing I was toying with was using deny as well as grant in
>>>>> policy files:
>>>>>
>>>>> Where denials would be checked first by the policy prior to checking
>>>>> grants:
>>>>>
>>>>> So you could deny a proxy access to the local network, whilst granting
>>>>> it
>>>>> access to the entire internet, with two simple policy statements.
>>>>>
>>>>> Or you could allow access to a directory, but deny access to a user
>>>>> policy
>>>>> file contained in that directory, for principal based grants.
>>>>>
>>>>> The syntax would be identical to a grant statement in policy files,
>>>>> except
>>>>> deny replaces grant.
>>>>>
>>>>> But then I realised despite the advantages, it adds complexity, because
>>>>> the deny statement could have unintended scope narrowing / widening
>>>>> consequences and Permissions like SocketPermission don't work as well as
>>>>> intended, it would be simpler to dynamically grant Permissions on an as
>>>>> needed basis.
>>>>>
>>>>> So any last remaining traces of deny must be removed.
>>>>>
>>>>> Instead of using deny in policy grants, I figure that proxy's can
>>>>> optionally include permissions.perms files under META-INF in their jar
>>>>> files as a hint to clients. By using the least priviledge model and
>>>>> limiting the GrantPermissions given to Principals administrators can
>>>>> limit
>>>>> Permissions users can grant to proxy's.
>>>>>
>>>>> The proxy developers would need to be aware they might not be granted
>>>>> all
>>>>> the permissions they'd like and offer reduced functionality by catching
>>>>> SecurityException.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Peter.
>>>>>
>>>>>
>>>>>
>>>
>>
>
>
Re: SVN Merge
Posted by Peter Firmstone <ji...@zeus.net.au>.
You are not going to believe which class is responsible for the test
regressions:
java.security.Permissions
It's not resolving an UnresolvedPermission, don't ask me why not, I
haven't inspected sun's version of the source, since I wrote my
implementation from Apache Harmony:
It is only being used in a single thread, never shared, it doesn't make
any sense, as you can see the permission is there, I've checked it,
swapping out Permissions for ConcurrentPermissions fixes it. This is
an old class, heavily used and tested in the wild, although I'm using it
differently by creating and discarding it after one use.
Go figure, guess I'm going to have to keep ConcurrentPermissions after
all. Bugger, that stuffs my refactoring plans! They were working out
so well too.
[java] ActSys-err: INFO: activation daemon started
[java] ActSys-err: SecurityManager: java.lang.SecurityManager@1989b5
[java] ActSys-err: Policy:
net.jini.security.policy.DynamicPolicyProvider@a00185
[java] ActSys-err: ProtectionDomain: ProtectionDomain (null <no
signer certificates>)
[java] ActSys-err: null
[java] ActSys-err: <no principals>
[java] ActSys-err: java.security.Permissions@e3849c (
[java] ActSys-err: (java.security.SecurityPermission getPolicy)
[java] ActSys-err: (java.lang.RuntimePermission stopThread)
[java] ActSys-err: (java.io.FilePermission
/opt/src/River_Fixed_2nd_Try/peterConcurrentPolicy/qa/lib/- read)
[java] ActSys-err: (java.net.SocketPermission localhost:1024-
listen,resolve)
[java] ActSys-err: (java.util.PropertyPermission line.separator read)
[java] ActSys-err: (java.util.PropertyPermission
java.vm.specification.version read)
[java] ActSys-err: (java.util.PropertyPermission java.vm.version read)
[java] ActSys-err: (java.util.PropertyPermission FILEPOLICY02 read)
[java] ActSys-err: (java.util.PropertyPermission java.vendor.url read)
[java] ActSys-err: (java.util.PropertyPermission
java.vm.specification.vendor read)
[java] ActSys-err: (java.util.PropertyPermission java.vm.name read)
[java] ActSys-err: (java.util.PropertyPermission os.name read)
[java] ActSys-err: (java.util.PropertyPermission
java.system.class.loader read)
[java] ActSys-err: (java.util.PropertyPermission java.vm.vendor read)
[java] ActSys-err: (java.util.PropertyPermission path.separator read)
[java] ActSys-err: (java.util.PropertyPermission
java.specification.name read)
[java] ActSys-err: (java.util.PropertyPermission os.version read)
[java] ActSys-err: (java.util.PropertyPermission
com.sun.jini.reggie.enableImplToStubReplacement read)
[java] ActSys-err: (java.util.PropertyPermission os.arch read)
[java] ActSys-err: (java.util.PropertyPermission
java.class.version read)
[java] ActSys-err: (java.util.PropertyPermission java.version read)
[java] ActSys-err: (java.util.PropertyPermission file.separator read)
[java] ActSys-err: (java.util.PropertyPermission java.vendor read)
[java] ActSys-err: (java.util.PropertyPermission
java.vm.specification.name read)
[java] ActSys-err: (java.util.PropertyPermission
java.specification.version read)
[java] ActSys-err: (java.util.PropertyPermission
java.specification.vendor read)
[java] ActSys-err: (unresolved com.sun.jini.phoenix.ExecPermission
/bin/javax )
[java] ActSys-err: (unresolved
com.sun.jini.phoenix.ExecOptionPermission * )
[java] ActSys-err: )
[java] ActSys-err:
[java] ActSys-err:
[java] com.sun.jini.qa.harness.TestException: Unexpected exception
starting service; nested exception is:
[java] Unexpected Exception
[java] at
com.sun.jini.qa.harness.SharedGroupAdmin.start(SharedGroupAdmin.java:218)
[java] at
com.sun.jini.qa.harness.AdminManager.startService(AdminManager.java:639)
[java] at
com.sun.jini.qa.harness.AdminManager.startService(AdminManager.java:660)
[java] at
com.sun.jini.test.impl.start.AbstractStartBaseTest.setup(AbstractStartBaseTest.java:64)
[java] at
com.sun.jini.qa.harness.MasterTest.doTest(MasterTest.java:217)
[java] at
com.sun.jini.qa.harness.MasterTest.main(MasterTest.java:142)
[java] Caused by: java.lang.RuntimeException: Unexpected Exception
[java] at
com.sun.jini.start.SharedActivationGroupDescriptor.create(SharedActivationGroupDescriptor.java:371)
[java] at
com.sun.jini.qa.harness.SharedGroupAdmin.start(SharedGroupAdmin.java:205)
[java] ... 5 more
[java] Caused by: java.security.AccessControlException: access
denied (com.sun.jini.phoenix.ExecOptionPermission
"-Dcom.sun.jini.qa.harness.harnessJar=/opt/src/River_Fixed_2nd_Try/peterConcurrentPolicy/qa/lib/jiniharness.jar")
[java] at
net.jini.jeri.BasicInvocationDispatcher.checkClientPermission(BasicInvocationDispatcher.java:950)
[java] at
com.sun.jini.phoenix.DefaultGroupPolicy.checkPermission(DefaultGroupPolicy.java:112)
[java] at
com.sun.jini.phoenix.DefaultGroupPolicy.checkGroup(DefaultGroupPolicy.java:81)
[java] at
com.sun.jini.phoenix.SystemAccessILFactory$SystemDispatcher.invoke(SystemAccessILFactory.java:289)
[java] at
net.jini.jeri.BasicInvocationDispatcher.dispatch(BasicInvocationDispatcher.java:609)
[java] at
com.sun.jini.jeri.internal.runtime.Target$2.run(Target.java:491)
[java] at
net.jini.export.ServerContext.doWithServerContext(ServerContext.java:103)
[java] at
com.sun.jini.jeri.internal.runtime.Target.dispatch(Target.java:488)
[java] at
com.sun.jini.jeri.internal.runtime.Target.access$000(Target.java:57)
[java] at
com.sun.jini.jeri.internal.runtime.Target$1.run(Target.java:464)
[java] at java.security.AccessController.doPrivileged(Native
Method)
[java] at
com.sun.jini.jeri.internal.runtime.Target.dispatch(Target.java:461)
[java] at
com.sun.jini.jeri.internal.runtime.Target.dispatch(Target.java:426)
[java] at
com.sun.jini.jeri.internal.runtime.DgcRequestDispatcher.dispatch(DgcRequestDispatcher.java:210)
[java] at
net.jini.jeri.connection.ServerConnectionManager$Dispatcher.dispatch(ServerConnectionManager.java:147)
[java] at
com.sun.jini.jeri.internal.mux.MuxServer$1$1.run(MuxServer.java:244)
[java] at java.security.AccessController.doPrivileged(Native
Method)
[java] at
com.sun.jini.jeri.internal.mux.MuxServer$1.run(MuxServer.java:241)
[java] at
com.sun.jini.thread.ThreadPool$Worker.run(ThreadPool.java:140)
[java] at java.lang.Thread.run(Thread.java:662)
[java] at
com.sun.jini.jeri.internal.runtime.Util.__________EXCEPTION_RECEIVED_FROM_SERVER__________(Util.java:108)
[java] at
com.sun.jini.jeri.internal.runtime.Util.exceptionReceivedFromServer(Util.java:101)
[java] at
net.jini.jeri.BasicInvocationHandler.unmarshalThrow(BasicInvocationHandler.java:1303)
[java] at
net.jini.jeri.BasicInvocationHandler.invokeRemoteMethodOnce(BasicInvocationHandler.java:832)
[java] at
net.jini.jeri.BasicInvocationHandler.invokeRemoteMethod(BasicInvocationHandler.java:659)
[java] at
net.jini.jeri.BasicInvocationHandler.invoke(BasicInvocationHandler.java:528)
[java] at $Proxy0.registerGroup(Unknown Source)
[java] at
com.sun.jini.start.SharedActivationGroupDescriptor.create(SharedActivationGroupDescriptor.java:354)
[java] ... 6 more
Peter Firmstone wrote:
> Looks like I've had some regressions.
>
> These tests were passing yesterday, so it must have something to do
> with some very recent changes, something to do with null CodeSource in
> ProtectionDomain's, I suspect.
>
> Regards,
>
> Peter.
>
> com/sun/jini/test/impl/start/ActivateWrapperActivateDescTest.td
> [java] Test Failed: Setup Failed:
> com.sun.jini.qa.harness.TestException: Unexpected exception starting
> service; nested exception is:
> [java] Unexpected Exception
> [java]
> [java] -----------------------------------------
> [java]
> com/sun/jini/test/impl/start/ActivateWrapperActivateDescTest2.td
> [java] Test Failed: Setup Failed:
> com.sun.jini.qa.harness.TestException: Unexpected exception starting
> service; nested exception is:
> [java] Unexpected Exception
> [java]
> [java] -----------------------------------------
> [java]
> com/sun/jini/test/impl/start/ActivateWrapperActivateDescTest3.td
> [java] Test Failed: Setup Failed:
> com.sun.jini.qa.harness.TestException: Unexpected exception starting
> service; nested exception is:
> [java] Unexpected Exception
> [java]
> [java] -----------------------------------------
> [java]
> com/sun/jini/test/impl/start/ActivateWrapperRegisterBadCodebase.td
> [java] Test Failed: Setup Failed:
> com.sun.jini.qa.harness.TestException: Unexpected exception starting
> service; nested exception is:
> [java] Unexpected Exception
> [java]
> [java] -----------------------------------------
> [java]
> com/sun/jini/test/impl/start/ActivateWrapperRegisterBadGroup.td
> [java] Test Failed: Setup Failed:
> com.sun.jini.qa.harness.TestException: Unexpected exception starting
> service; nested exception is:
> [java] Unexpected Exception
> [java]
> [java] -----------------------------------------
> [java]
> com/sun/jini/test/impl/start/ActivateWrapperRegisterBadImplClass.td
> [java] Test Failed: Setup Failed:
> com.sun.jini.qa.harness.TestException: Unexpected exception starting
> service; nested exception is:
> [java] Unexpected Exception
> [java]
> [java] -----------------------------------------
> [java]
> com/sun/jini/test/impl/start/ActivateWrapperRegisterBadStubClass.td
> [java] Test Skipped: verifiers are:
> com.sun.jini.qa.harness.SkipPostJDK14TestVerifier
> [java] -----------------------------------------
> [java]
> com/sun/jini/test/impl/start/ActivateWrapperRegisterBadStubCodebase.td
> [java] Test Failed: Setup Failed:
> com.sun.jini.qa.harness.TestException: Unexpected exception starting
> service; nested exception is:
> [java] Unexpected Exception
> [java]
> [java] -----------------------------------------
> [java]
> com/sun/jini/test/impl/start/ActivateWrapperRegisterUnsharedImpl.td
> [java] Test Failed: Setup Failed:
> com.sun.jini.qa.harness.TestException: Unexpected exception starting
> service; nested exception is:
> [java] Unexpected Exception
> [java]
> [java] -----------------------------------------
> [java] com/sun/jini/test/impl/start/ClassLoaderTest.td
> [java] Test Failed: Setup Failed:
> com.sun.jini.qa.harness.TestException: Unexpected exception starting
> service; nested exception is:
> [java] Unexpected Exception
> [java]
> [java] -----------------------------------------
> [java] com/sun/jini/test/impl/start/ClassLoaderUtilTest.td
> [java] Test Failed: Setup Failed:
> com.sun.jini.qa.harness.TestException: Unexpected exception starting
> service; nested exception is:
> [java] Unexpected Exception
> [java]
> [java] -----------------------------------------
> [java] com/sun/jini/test/impl/start/ClasspathTest.td
> [java] Test Failed: Setup Failed:
> com.sun.jini.qa.harness.TestException: Unexpected exception starting
> service; nested exception is:
> [java] Unexpected Exception
> [java]
> [java] -----------------------------------------
> [java] com/sun/jini/test/impl/start/CodebaseTest.td
> [java] Test Failed: Setup Failed:
> com.sun.jini.qa.harness.TestException: Unexpected exception starting
> service; nested exception is:
> [java] Unexpected Exception
> [java]
> [java] -----------------------------------------
> [java]
> com/sun/jini/test/impl/start/DestroySharedGroupCreateBadDesc.td
> [java] Test Failed: Setup Failed:
> com.sun.jini.qa.harness.TestException: Unexpected exception starting
> service; nested exception is:
> [java] Unexpected Exception
> [java]
> [java] -----------------------------------------
> [java]
> com/sun/jini/test/impl/start/DestroySharedGroupCreateEmptyTest.td
> [java] Test Failed: Setup Failed:
> com.sun.jini.qa.harness.TestException: Unexpected exception starting
> service; nested exception is:
> [java] Unexpected Exception
> [java]
> [java] -----------------------------------------
> [java]
> com/sun/jini/test/impl/start/DestroySharedGroupMainEmptyArgs.td
> [java] Test Failed: Setup Failed:
> com.sun.jini.qa.harness.TestException: Unexpected exception starting
> service; nested exception is:
> [java] Unexpected Exception
> [java]
> [java] -----------------------------------------
> [java]
> com/sun/jini/test/impl/start/DestroySharedGroupMainEmptyConfig.td
> [java] Test Failed: Setup Failed:
> com.sun.jini.qa.harness.TestException: Unexpected exception starting
> service; nested exception is:
> [java] Unexpected Exception
> [java]
> [java] -----------------------------------------
> [java]
> com/sun/jini/test/impl/start/DestroySharedGroupMainMissingConfig.td
> [java] Test Failed: Setup Failed:
> com.sun.jini.qa.harness.TestException: Unexpected exception starting
> service; nested exception is:
> [java] Unexpected Exception
> [java]
> [java] -----------------------------------------
> [java] com/sun/jini/test/impl/start/ExportClassLoaderTest.td
> [java] Test Failed: Setup Failed:
> com.sun.jini.qa.harness.TestException: Unexpected exception starting
> service; nested exception is:
> [java] Unexpected Exception
> [java]
> [java] -----------------------------------------
> [java] com/sun/jini/test/impl/start/MemberGroupsProblem.td
> [java] Test Skipped: verifiers are:
> com.sun.jini.qa.harness.SkipTestVerifier
> [java] -----------------------------------------
> [java] com/sun/jini/test/impl/start/MultipleClasspathComponentTest.td
> [java] Test Failed: Setup Failed:
> com.sun.jini.qa.harness.TestException: Unexpected exception starting
> service; nested exception is:
> [java] Unexpected Exception
> [java]
> [java] -----------------------------------------
> [java]
> com/sun/jini/test/impl/start/NonActivatableServiceDescriptorTest.td
> [java] Test Failed: Setup Failed:
> com.sun.jini.qa.harness.TestException: Unexpected exception starting
> service; nested exception is:
> [java] Unexpected Exception
> [java]
> [java] -----------------------------------------
> [java]
> com/sun/jini/test/impl/start/NonActivatableServiceDescriptorTest2.td
> [java] Test Failed: Setup Failed:
> com.sun.jini.qa.harness.TestException: Unexpected exception starting
> service; nested exception is:
> [java] Unexpected Exception
> [java]
> [java] -----------------------------------------
> [java] com/sun/jini/test/impl/start/SecurityTest.td
> [java] Test Failed: Setup Failed:
> com.sun.jini.qa.harness.TestException: Unexpected exception starting
> service; nested exception is:
> [java] Unexpected Exception
> [java]
> [java] -----------------------------------------
> [java] com/sun/jini/test/impl/start/SecurityTestNonActivatable.td
> [java] Test Failed: Setup Failed:
> com.sun.jini.qa.harness.TestException: Unexpected exception starting
> service; nested exception is:
> [java] Unexpected Exception
> [java]
> [java] -----------------------------------------
> [java] com/sun/jini/test/impl/start/SerializedServiceDescriptors.td
> [java] Test Failed: Setup Failed:
> com.sun.jini.qa.harness.TestException: Unexpected exception starting
> service; nested exception is:
> [java] Unexpected Exception
> [java]
> [java] -----------------------------------------
> [java]
> com/sun/jini/test/impl/start/ServiceDescriptorProxyPreparationTest.td
> [java] Test Failed: Setup Failed:
> com.sun.jini.qa.harness.TestException: Unexpected exception starting
> service; nested exception is:
> [java] Unexpected Exception
> [java]
> [java] -----------------------------------------
> [java]
> com/sun/jini/test/impl/start/ServiceStarterCreateActivatableNoConsServiceTest.td
>
> [java] Test Failed: Setup Failed:
> com.sun.jini.qa.harness.TestException: Unexpected exception starting
> service; nested exception is:
> [java] Unexpected Exception
> [java]
> [java] -----------------------------------------
> [java] com/sun/jini/test/impl/start/ServiceStarterCreateBadDesc.td
> [java] Test Failed: Setup Failed:
> com.sun.jini.qa.harness.TestException: Unexpected exception starting
> service; nested exception is:
> [java] Unexpected Exception
> [java]
> [java] -----------------------------------------
> [java]
> com/sun/jini/test/impl/start/ServiceStarterCreateBadDescWithLogin.td
> [java] Test Skipped: verifiers are:
> com.sun.jini.qa.harness.SkipConfigTestVerifier
> [java] -----------------------------------------
> [java]
> com/sun/jini/test/impl/start/ServiceStarterCreateBadServiceProxyAccessorTest.td
>
> [java] Test Failed: Setup Failed:
> com.sun.jini.qa.harness.TestException: Unexpected exception starting
> service; nested exception is:
> [java] Unexpected Exception
> [java]
> [java] -----------------------------------------
> [java]
> com/sun/jini/test/impl/start/ServiceStarterCreateBadTransientServiceTest.td
>
> [java] Test Failed: Setup Failed:
> com.sun.jini.qa.harness.TestException: Unexpected exception starting
> service; nested exception is:
> [java] Unexpected Exception
> [java]
> [java] -----------------------------------------
> [java] com/sun/jini/test/impl/start/ServiceStarterCreateEmptyTest.td
> [java] Test Failed: Setup Failed:
> com.sun.jini.qa.harness.TestException: Unexpected exception starting
> service; nested exception is:
> [java] Unexpected Exception
> [java]
> [java] -----------------------------------------
> [java]
> com/sun/jini/test/impl/start/ServiceStarterCreateSharedBadActServiceTest.td
>
> [java] Test Failed: Setup Failed:
> com.sun.jini.qa.harness.TestException: Unexpected exception starting
> service; nested exception is:
> [java] Unexpected Exception
> [java]
> [java] -----------------------------------------
> [java]
> com/sun/jini/test/impl/start/ServiceStarterCreateSharedGroupTest.td
> [java] Test Failed: Setup Failed:
> com.sun.jini.qa.harness.TestException: Unexpected exception starting
> service; nested exception is:
> [java] Unexpected Exception
> [java]
> [java] -----------------------------------------
> [java]
> com/sun/jini/test/impl/start/ServiceStarterCreateTransientNoConsServiceTest.td
>
> [java] Test Failed: Setup Failed:
> com.sun.jini.qa.harness.TestException: Unexpected exception starting
> service; nested exception is:
> [java] Unexpected Exception
> [java]
> [java] -----------------------------------------
> [java]
> com/sun/jini/test/impl/start/ServiceStarterCreateTransientServiceTest.td
> [java] Test Failed: Setup Failed:
> com.sun.jini.qa.harness.TestException: Unexpected exception starting
> service; nested exception is:
> [java] Unexpected Exception
> [java]
> [java] -----------------------------------------
> [java] com/sun/jini/test/impl/start/ServiceStarterMainEmptyArgs.td
> [java] Test Failed: Setup Failed:
> com.sun.jini.qa.harness.TestException: Unexpected exception starting
> service; nested exception is:
> [java] Unexpected Exception
> [java]
> [java] -----------------------------------------
> [java] com/sun/jini/test/impl/start/ServiceStarterMainEmptyConfig.td
> [java] Test Failed: Setup Failed:
> com.sun.jini.qa.harness.TestException: Unexpected exception starting
> service; nested exception is:
> [java] Unexpected Exception
> [java]
> [java] -----------------------------------------
> [java]
> com/sun/jini/test/impl/start/ServiceStarterMainMissingConfig.td
> [java] Test Failed: Setup Failed:
> com.sun.jini.qa.harness.TestException: Unexpected exception starting
> service; nested exception is:
> [java] Unexpected Exception
> [java]
> [java] -----------------------------------------
> [java]
> com/sun/jini/test/impl/start/SharedActivatableServiceDescriptorTest.td
> [java] Test Failed: Setup Failed:
> com.sun.jini.qa.harness.TestException: Unexpected exception starting
> service; nested exception is:
> [java] Unexpected Exception
> [java]
> [java] -----------------------------------------
> [java]
> com/sun/jini/test/impl/start/SharedActivatableServiceDescriptorTest2.td
> [java] Test Failed: Setup Failed:
> com.sun.jini.qa.harness.TestException: Unexpected exception starting
> service; nested exception is:
> [java] Unexpected Exception
> [java]
> [java] -----------------------------------------
> [java]
> com/sun/jini/test/impl/start/SharedActivatableServiceDescriptorTest3.td
> [java] Test Failed: Setup Failed:
> com.sun.jini.qa.harness.TestException: Unexpected exception starting
> service; nested exception is:
> [java] Unexpected Exception
> [java]
> [java] -----------------------------------------
> [java]
> com/sun/jini/test/impl/start/SharedActivationGroupDescriptorTest.td
> [java] Test Failed: Setup Failed:
> com.sun.jini.qa.harness.TestException: Unexpected exception starting
> service; nested exception is:
> [java] Unexpected Exception
> [java]
> [java] -----------------------------------------
> [java]
> com/sun/jini/test/impl/start/SharedActivationPolicyPermissionActionsTest.td
>
> [java] Test Failed: Setup Failed:
> com.sun.jini.qa.harness.TestException: Unexpected exception starting
> service; nested exception is:
> [java] Unexpected Exception
> [java]
> [java] -----------------------------------------
> [java]
> com/sun/jini/test/impl/start/SharedActivationPolicyPermissionCollectionTest.td
>
> [java] Test Failed: Setup Failed:
> com.sun.jini.qa.harness.TestException: Unexpected exception starting
> service; nested exception is:
> [java] Unexpected Exception
> [java]
> [java] -----------------------------------------
> [java]
> com/sun/jini/test/impl/start/SharedActivationPolicyPermissionEqualsTest.td
>
> [java] Test Failed: Setup Failed:
> com.sun.jini.qa.harness.TestException: Unexpected exception starting
> service; nested exception is:
> [java] Unexpected Exception
> [java]
> [java] -----------------------------------------
> [java]
> com/sun/jini/test/impl/start/SharedActivationPolicyPermissionHTTPEqualsTest.td
>
> [java] Test Failed: Setup Failed:
> com.sun.jini.qa.harness.TestException: Unexpected exception starting
> service; nested exception is:
> [java] Unexpected Exception
> [java]
> [java] -----------------------------------------
> [java]
> com/sun/jini/test/impl/start/SharedActivationPolicyPermissionHTTPImpliesTest.td
>
> [java] Test Failed: Setup Failed:
> com.sun.jini.qa.harness.TestException: Unexpected exception starting
> service; nested exception is:
> [java] Unexpected Exception
> [java]
> [java] -----------------------------------------
> [java]
> com/sun/jini/test/impl/start/SharedActivationPolicyPermissionImpliesTest.td
>
> [java] Test Failed: Setup Failed:
> com.sun.jini.qa.harness.TestException: Unexpected exception starting
> service; nested exception is:
> [java] Unexpected Exception
> [java]
> [java] -----------------------------------------
> [java] com/sun/jini/test/impl/start/SharedGroupNullConfigEntries.td
> [java] Test Failed: Test Failed:
> com.sun.jini.qa.harness.TestException: Service failed due to
> non-configuration relatedexception.
> [java]
> [java] -----------------------------------------
> [java] com/sun/jini/test/impl/start/SharedGroupProxyEqualityTest.td
> [java] Test Failed: Test Failed:
> com.sun.jini.qa.harness.TestException: Problem creating service for
> com.sun.jini.start.SharedGroup; nested exception is:
> [java] Failed to start global shared group; nested exception is:
> [java] Unexpected exception starting service; nested exception
> is:
> [java] Unexpected Exception
> [java]
> [java] -----------------------------------------
> [java] com/sun/jini/test/impl/start/StartAllServicesTest.td
> [java] Test Failed: Setup Failed:
> com.sun.jini.qa.harness.TestException: Unexpected exception starting
> service; nested exception is:
> [java] Unexpected Exception
>
>
>
> Tom Hobbs wrote:
>> I can try and find some time for you. Let me know what you need and
>> I'll
>> do my best.
>>
>> Sent via mobile device, please forgive typos and spacing errors.
>>
>> On 10 Jan 2012 12:17, "Peter Firmstone" <ji...@zeus.net.au> wrote:
>>
>>
>>> Tom & Dan, thanks for the support, we're probably looking at a dry
>>> run by
>>> the weekend, right now I'm running the tests again, this run is
>>> expected to
>>> pass, I'm just checking for any regressions (same code in svn).
>>> I'll clean
>>> out all the redundant code, followed by some refactoring to move new
>>> public
>>> utility classes into package private where possible.
>>>
>>> I've you've got some time, I could use a hand to go over the new
>>> code to
>>> tidy up any loose ends, make sure any new public api looks right
>>> before we
>>> merge, so we can release quickly, once the merge is complete.
>>>
>>> At this point, the code's only been tested on sparc.
>>>
>>> Cheers,
>>>
>>> Peter.
>>>
>>> Dan Creswell wrote:
>>>
>>>
>>>> Agreed, remember --dry-run will give you a preview of what's to come
>>>> in a merge if you have concerns...
>>>>
>>>> On 10 January 2012 10:08, Tom Hobbs <tv...@googlemail.com> wrote:
>>>>
>>>>
>>>>
>>>>> Let SVN do the merge, your changes might be extensive but I doubt
>>>>> there
>>>>> has
>>>>> been much movement in those files since you checked them out. So the
>>>>> merge
>>>>> will probably be more of a replace.
>>>>>
>>>>> I'm hoping to get some coding done in the next few weeks - at
>>>>> last! So we
>>>>> might have enough changes soon for a release.
>>>>>
>>>>> Keep up the good work, Peter.
>>>>>
>>>>> Sent via mobile device, please forgive typos and spacing errors.
>>>>>
>>>>> On 10 Jan 2012 06:20, "Peter" <ji...@zeus.net.au> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> The new security manager and policies are almost ready to merge back
>>>>>> into
>>>>>> trunk.
>>>>>>
>>>>>> Any svn merge tips would be much appreciated.
>>>>>>
>>>>>> First, I'd like to move some policy implementation classes that
>>>>>> are at
>>>>>> present public in org.apache.river.*, into package private
>>>>>> net.jini.*
>>>>>> namespaces, to reduce the public api.
>>>>>>
>>>>>> Not all of the code will be included, classes, like
>>>>>> ConcurrentPermissions
>>>>>> (and all policy cache associated classes), even though far better
>>>>>> than
>>>>>> Permissions, will be discarded, as recent developments (eliminating
>>>>>> policy
>>>>>> cache) have made them redundant.
>>>>>>
>>>>>> DelegatePermission is still there, designed to work with delegate
>>>>>> wrapper
>>>>>> classes that encapsulate sockets and and file handles, to enable
>>>>>> removal of
>>>>>> temporarily granted permissions.
>>>>>>
>>>>>> Example: A downloaded proxy is granted a SocketPermission to
>>>>>> contact its
>>>>>> server, if during deserialisation, the proxy modifies some public
>>>>>> static
>>>>>> fields (java.xml.* vulnerabilities ring a bell?) by replacing some
>>>>>> platform
>>>>>> classes with its own, it leaves some of its own proxy code on the
>>>>>> stack
>>>>>> context. The proxy after being downloaded is found to be
>>>>>> untrusted and
>>>>>> discarded.
>>>>>>
>>>>>> Every time the object the proxy has injected into the platform is
>>>>>> accessed, it steals information and sends it back to its originating
>>>>>> host.
>>>>>>
>>>>>> If a DelegatePermission(**SocketPermission p) is granted instead,
>>>>>> the
>>>>>> proxy
>>>>>> recieves a socket that denies access when the permission is revoked,
>>>>>> when
>>>>>> trust can't be verified.
>>>>>>
>>>>>> The proxy could still perform a denial of service, by causing an
>>>>>> out of
>>>>>> memory error during deserialisation.
>>>>>>
>>>>>> DelegatePermission can also be used to grant temporary or limited
>>>>>> access
>>>>>> to Principals, eg after downloading 1GB, downloads are revoked and
>>>>>> regranted at the next monthly cycle, something sililar could be
>>>>>> used to
>>>>>> limit writes to the file system.
>>>>>>
>>>>>> Obviously you'll need to buffer the input or output streams, to
>>>>>> balance
>>>>>> how often checks are performed, that is, if you choose to utilise
>>>>>> it.
>>>>>>
>>>>>> A DelegateSocketFactory that can be used to encapsulate existing
>>>>>> SocketFactory's will be released at a later date to enable
>>>>>> DelegatePermission controlled streams and channels. Note any
>>>>>> ProtectionDomains with SocketPermission will still have access to
>>>>>> the
>>>>>> same
>>>>>> channel.
>>>>>>
>>>>>> DelegatePermission is intended to be a dynamically or runtime
>>>>>> granted
>>>>>> Permission.
>>>>>>
>>>>>> To function it requires a DelegateSecurityManager, each stack
>>>>>> context
>>>>>> domain must have permission either for the DelegatePermission or
>>>>>> it's
>>>>>> representative Permission.
>>>>>>
>>>>>> This was one motivation for a securitymanager cache, it needed to
>>>>>> be as
>>>>>> fast as possible and non blocking, unlike policy cache.
>>>>>>
>>>>>> Using delegates is of course optional.
>>>>>>
>>>>>> The other thing I was toying with was using deny as well as grant in
>>>>>> policy files:
>>>>>>
>>>>>> Where denials would be checked first by the policy prior to checking
>>>>>> grants:
>>>>>>
>>>>>> So you could deny a proxy access to the local network, whilst
>>>>>> granting
>>>>>> it
>>>>>> access to the entire internet, with two simple policy statements.
>>>>>>
>>>>>> Or you could allow access to a directory, but deny access to a user
>>>>>> policy
>>>>>> file contained in that directory, for principal based grants.
>>>>>>
>>>>>> The syntax would be identical to a grant statement in policy files,
>>>>>> except
>>>>>> deny replaces grant.
>>>>>>
>>>>>> But then I realised despite the advantages, it adds complexity,
>>>>>> because
>>>>>> the deny statement could have unintended scope narrowing / widening
>>>>>> consequences and Permissions like SocketPermission don't work as
>>>>>> well as
>>>>>> intended, it would be simpler to dynamically grant Permissions on
>>>>>> an as
>>>>>> needed basis.
>>>>>>
>>>>>> So any last remaining traces of deny must be removed.
>>>>>>
>>>>>> Instead of using deny in policy grants, I figure that proxy's can
>>>>>> optionally include permissions.perms files under META-INF in
>>>>>> their jar
>>>>>> files as a hint to clients. By using the least priviledge model and
>>>>>> limiting the GrantPermissions given to Principals administrators can
>>>>>> limit
>>>>>> Permissions users can grant to proxy's.
>>>>>>
>>>>>> The proxy developers would need to be aware they might not be
>>>>>> granted
>>>>>> all
>>>>>> the permissions they'd like and offer reduced functionality by
>>>>>> catching
>>>>>> SecurityException.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Peter.
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>
>>
>
>
Re: SVN Merge
Posted by Peter Firmstone <ji...@zeus.net.au>.
Looks like I've had some regressions.
These tests were passing yesterday, so it must have something to do with
some very recent changes, something to do with null CodeSource in
ProtectionDomain's, I suspect.
Regards,
Peter.
com/sun/jini/test/impl/start/ActivateWrapperActivateDescTest.td
[java] Test Failed: Setup Failed:
com.sun.jini.qa.harness.TestException: Unexpected exception starting
service; nested exception is:
[java] Unexpected Exception
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/start/ActivateWrapperActivateDescTest2.td
[java] Test Failed: Setup Failed:
com.sun.jini.qa.harness.TestException: Unexpected exception starting
service; nested exception is:
[java] Unexpected Exception
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/start/ActivateWrapperActivateDescTest3.td
[java] Test Failed: Setup Failed:
com.sun.jini.qa.harness.TestException: Unexpected exception starting
service; nested exception is:
[java] Unexpected Exception
[java]
[java] -----------------------------------------
[java]
com/sun/jini/test/impl/start/ActivateWrapperRegisterBadCodebase.td
[java] Test Failed: Setup Failed:
com.sun.jini.qa.harness.TestException: Unexpected exception starting
service; nested exception is:
[java] Unexpected Exception
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/start/ActivateWrapperRegisterBadGroup.td
[java] Test Failed: Setup Failed:
com.sun.jini.qa.harness.TestException: Unexpected exception starting
service; nested exception is:
[java] Unexpected Exception
[java]
[java] -----------------------------------------
[java]
com/sun/jini/test/impl/start/ActivateWrapperRegisterBadImplClass.td
[java] Test Failed: Setup Failed:
com.sun.jini.qa.harness.TestException: Unexpected exception starting
service; nested exception is:
[java] Unexpected Exception
[java]
[java] -----------------------------------------
[java]
com/sun/jini/test/impl/start/ActivateWrapperRegisterBadStubClass.td
[java] Test Skipped: verifiers are:
com.sun.jini.qa.harness.SkipPostJDK14TestVerifier
[java] -----------------------------------------
[java]
com/sun/jini/test/impl/start/ActivateWrapperRegisterBadStubCodebase.td
[java] Test Failed: Setup Failed:
com.sun.jini.qa.harness.TestException: Unexpected exception starting
service; nested exception is:
[java] Unexpected Exception
[java]
[java] -----------------------------------------
[java]
com/sun/jini/test/impl/start/ActivateWrapperRegisterUnsharedImpl.td
[java] Test Failed: Setup Failed:
com.sun.jini.qa.harness.TestException: Unexpected exception starting
service; nested exception is:
[java] Unexpected Exception
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/start/ClassLoaderTest.td
[java] Test Failed: Setup Failed:
com.sun.jini.qa.harness.TestException: Unexpected exception starting
service; nested exception is:
[java] Unexpected Exception
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/start/ClassLoaderUtilTest.td
[java] Test Failed: Setup Failed:
com.sun.jini.qa.harness.TestException: Unexpected exception starting
service; nested exception is:
[java] Unexpected Exception
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/start/ClasspathTest.td
[java] Test Failed: Setup Failed:
com.sun.jini.qa.harness.TestException: Unexpected exception starting
service; nested exception is:
[java] Unexpected Exception
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/start/CodebaseTest.td
[java] Test Failed: Setup Failed:
com.sun.jini.qa.harness.TestException: Unexpected exception starting
service; nested exception is:
[java] Unexpected Exception
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/start/DestroySharedGroupCreateBadDesc.td
[java] Test Failed: Setup Failed:
com.sun.jini.qa.harness.TestException: Unexpected exception starting
service; nested exception is:
[java] Unexpected Exception
[java]
[java] -----------------------------------------
[java]
com/sun/jini/test/impl/start/DestroySharedGroupCreateEmptyTest.td
[java] Test Failed: Setup Failed:
com.sun.jini.qa.harness.TestException: Unexpected exception starting
service; nested exception is:
[java] Unexpected Exception
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/start/DestroySharedGroupMainEmptyArgs.td
[java] Test Failed: Setup Failed:
com.sun.jini.qa.harness.TestException: Unexpected exception starting
service; nested exception is:
[java] Unexpected Exception
[java]
[java] -----------------------------------------
[java]
com/sun/jini/test/impl/start/DestroySharedGroupMainEmptyConfig.td
[java] Test Failed: Setup Failed:
com.sun.jini.qa.harness.TestException: Unexpected exception starting
service; nested exception is:
[java] Unexpected Exception
[java]
[java] -----------------------------------------
[java]
com/sun/jini/test/impl/start/DestroySharedGroupMainMissingConfig.td
[java] Test Failed: Setup Failed:
com.sun.jini.qa.harness.TestException: Unexpected exception starting
service; nested exception is:
[java] Unexpected Exception
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/start/ExportClassLoaderTest.td
[java] Test Failed: Setup Failed:
com.sun.jini.qa.harness.TestException: Unexpected exception starting
service; nested exception is:
[java] Unexpected Exception
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/start/MemberGroupsProblem.td
[java] Test Skipped: verifiers are:
com.sun.jini.qa.harness.SkipTestVerifier
[java] -----------------------------------------
[java] com/sun/jini/test/impl/start/MultipleClasspathComponentTest.td
[java] Test Failed: Setup Failed:
com.sun.jini.qa.harness.TestException: Unexpected exception starting
service; nested exception is:
[java] Unexpected Exception
[java]
[java] -----------------------------------------
[java]
com/sun/jini/test/impl/start/NonActivatableServiceDescriptorTest.td
[java] Test Failed: Setup Failed:
com.sun.jini.qa.harness.TestException: Unexpected exception starting
service; nested exception is:
[java] Unexpected Exception
[java]
[java] -----------------------------------------
[java]
com/sun/jini/test/impl/start/NonActivatableServiceDescriptorTest2.td
[java] Test Failed: Setup Failed:
com.sun.jini.qa.harness.TestException: Unexpected exception starting
service; nested exception is:
[java] Unexpected Exception
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/start/SecurityTest.td
[java] Test Failed: Setup Failed:
com.sun.jini.qa.harness.TestException: Unexpected exception starting
service; nested exception is:
[java] Unexpected Exception
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/start/SecurityTestNonActivatable.td
[java] Test Failed: Setup Failed:
com.sun.jini.qa.harness.TestException: Unexpected exception starting
service; nested exception is:
[java] Unexpected Exception
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/start/SerializedServiceDescriptors.td
[java] Test Failed: Setup Failed:
com.sun.jini.qa.harness.TestException: Unexpected exception starting
service; nested exception is:
[java] Unexpected Exception
[java]
[java] -----------------------------------------
[java]
com/sun/jini/test/impl/start/ServiceDescriptorProxyPreparationTest.td
[java] Test Failed: Setup Failed:
com.sun.jini.qa.harness.TestException: Unexpected exception starting
service; nested exception is:
[java] Unexpected Exception
[java]
[java] -----------------------------------------
[java]
com/sun/jini/test/impl/start/ServiceStarterCreateActivatableNoConsServiceTest.td
[java] Test Failed: Setup Failed:
com.sun.jini.qa.harness.TestException: Unexpected exception starting
service; nested exception is:
[java] Unexpected Exception
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/start/ServiceStarterCreateBadDesc.td
[java] Test Failed: Setup Failed:
com.sun.jini.qa.harness.TestException: Unexpected exception starting
service; nested exception is:
[java] Unexpected Exception
[java]
[java] -----------------------------------------
[java]
com/sun/jini/test/impl/start/ServiceStarterCreateBadDescWithLogin.td
[java] Test Skipped: verifiers are:
com.sun.jini.qa.harness.SkipConfigTestVerifier
[java] -----------------------------------------
[java]
com/sun/jini/test/impl/start/ServiceStarterCreateBadServiceProxyAccessorTest.td
[java] Test Failed: Setup Failed:
com.sun.jini.qa.harness.TestException: Unexpected exception starting
service; nested exception is:
[java] Unexpected Exception
[java]
[java] -----------------------------------------
[java]
com/sun/jini/test/impl/start/ServiceStarterCreateBadTransientServiceTest.td
[java] Test Failed: Setup Failed:
com.sun.jini.qa.harness.TestException: Unexpected exception starting
service; nested exception is:
[java] Unexpected Exception
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/start/ServiceStarterCreateEmptyTest.td
[java] Test Failed: Setup Failed:
com.sun.jini.qa.harness.TestException: Unexpected exception starting
service; nested exception is:
[java] Unexpected Exception
[java]
[java] -----------------------------------------
[java]
com/sun/jini/test/impl/start/ServiceStarterCreateSharedBadActServiceTest.td
[java] Test Failed: Setup Failed:
com.sun.jini.qa.harness.TestException: Unexpected exception starting
service; nested exception is:
[java] Unexpected Exception
[java]
[java] -----------------------------------------
[java]
com/sun/jini/test/impl/start/ServiceStarterCreateSharedGroupTest.td
[java] Test Failed: Setup Failed:
com.sun.jini.qa.harness.TestException: Unexpected exception starting
service; nested exception is:
[java] Unexpected Exception
[java]
[java] -----------------------------------------
[java]
com/sun/jini/test/impl/start/ServiceStarterCreateTransientNoConsServiceTest.td
[java] Test Failed: Setup Failed:
com.sun.jini.qa.harness.TestException: Unexpected exception starting
service; nested exception is:
[java] Unexpected Exception
[java]
[java] -----------------------------------------
[java]
com/sun/jini/test/impl/start/ServiceStarterCreateTransientServiceTest.td
[java] Test Failed: Setup Failed:
com.sun.jini.qa.harness.TestException: Unexpected exception starting
service; nested exception is:
[java] Unexpected Exception
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/start/ServiceStarterMainEmptyArgs.td
[java] Test Failed: Setup Failed:
com.sun.jini.qa.harness.TestException: Unexpected exception starting
service; nested exception is:
[java] Unexpected Exception
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/start/ServiceStarterMainEmptyConfig.td
[java] Test Failed: Setup Failed:
com.sun.jini.qa.harness.TestException: Unexpected exception starting
service; nested exception is:
[java] Unexpected Exception
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/start/ServiceStarterMainMissingConfig.td
[java] Test Failed: Setup Failed:
com.sun.jini.qa.harness.TestException: Unexpected exception starting
service; nested exception is:
[java] Unexpected Exception
[java]
[java] -----------------------------------------
[java]
com/sun/jini/test/impl/start/SharedActivatableServiceDescriptorTest.td
[java] Test Failed: Setup Failed:
com.sun.jini.qa.harness.TestException: Unexpected exception starting
service; nested exception is:
[java] Unexpected Exception
[java]
[java] -----------------------------------------
[java]
com/sun/jini/test/impl/start/SharedActivatableServiceDescriptorTest2.td
[java] Test Failed: Setup Failed:
com.sun.jini.qa.harness.TestException: Unexpected exception starting
service; nested exception is:
[java] Unexpected Exception
[java]
[java] -----------------------------------------
[java]
com/sun/jini/test/impl/start/SharedActivatableServiceDescriptorTest3.td
[java] Test Failed: Setup Failed:
com.sun.jini.qa.harness.TestException: Unexpected exception starting
service; nested exception is:
[java] Unexpected Exception
[java]
[java] -----------------------------------------
[java]
com/sun/jini/test/impl/start/SharedActivationGroupDescriptorTest.td
[java] Test Failed: Setup Failed:
com.sun.jini.qa.harness.TestException: Unexpected exception starting
service; nested exception is:
[java] Unexpected Exception
[java]
[java] -----------------------------------------
[java]
com/sun/jini/test/impl/start/SharedActivationPolicyPermissionActionsTest.td
[java] Test Failed: Setup Failed:
com.sun.jini.qa.harness.TestException: Unexpected exception starting
service; nested exception is:
[java] Unexpected Exception
[java]
[java] -----------------------------------------
[java]
com/sun/jini/test/impl/start/SharedActivationPolicyPermissionCollectionTest.td
[java] Test Failed: Setup Failed:
com.sun.jini.qa.harness.TestException: Unexpected exception starting
service; nested exception is:
[java] Unexpected Exception
[java]
[java] -----------------------------------------
[java]
com/sun/jini/test/impl/start/SharedActivationPolicyPermissionEqualsTest.td
[java] Test Failed: Setup Failed:
com.sun.jini.qa.harness.TestException: Unexpected exception starting
service; nested exception is:
[java] Unexpected Exception
[java]
[java] -----------------------------------------
[java]
com/sun/jini/test/impl/start/SharedActivationPolicyPermissionHTTPEqualsTest.td
[java] Test Failed: Setup Failed:
com.sun.jini.qa.harness.TestException: Unexpected exception starting
service; nested exception is:
[java] Unexpected Exception
[java]
[java] -----------------------------------------
[java]
com/sun/jini/test/impl/start/SharedActivationPolicyPermissionHTTPImpliesTest.td
[java] Test Failed: Setup Failed:
com.sun.jini.qa.harness.TestException: Unexpected exception starting
service; nested exception is:
[java] Unexpected Exception
[java]
[java] -----------------------------------------
[java]
com/sun/jini/test/impl/start/SharedActivationPolicyPermissionImpliesTest.td
[java] Test Failed: Setup Failed:
com.sun.jini.qa.harness.TestException: Unexpected exception starting
service; nested exception is:
[java] Unexpected Exception
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/start/SharedGroupNullConfigEntries.td
[java] Test Failed: Test Failed:
com.sun.jini.qa.harness.TestException: Service failed due to
non-configuration relatedexception.
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/start/SharedGroupProxyEqualityTest.td
[java] Test Failed: Test Failed:
com.sun.jini.qa.harness.TestException: Problem creating service for
com.sun.jini.start.SharedGroup; nested exception is:
[java] Failed to start global shared group; nested exception is:
[java] Unexpected exception starting service; nested exception is:
[java] Unexpected Exception
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/start/StartAllServicesTest.td
[java] Test Failed: Setup Failed:
com.sun.jini.qa.harness.TestException: Unexpected exception starting
service; nested exception is:
[java] Unexpected Exception
Tom Hobbs wrote:
> I can try and find some time for you. Let me know what you need and I'll
> do my best.
>
> Sent via mobile device, please forgive typos and spacing errors.
>
> On 10 Jan 2012 12:17, "Peter Firmstone" <ji...@zeus.net.au> wrote:
>
>
>> Tom & Dan, thanks for the support, we're probably looking at a dry run by
>> the weekend, right now I'm running the tests again, this run is expected to
>> pass, I'm just checking for any regressions (same code in svn). I'll clean
>> out all the redundant code, followed by some refactoring to move new public
>> utility classes into package private where possible.
>>
>> I've you've got some time, I could use a hand to go over the new code to
>> tidy up any loose ends, make sure any new public api looks right before we
>> merge, so we can release quickly, once the merge is complete.
>>
>> At this point, the code's only been tested on sparc.
>>
>> Cheers,
>>
>> Peter.
>>
>> Dan Creswell wrote:
>>
>>
>>> Agreed, remember --dry-run will give you a preview of what's to come
>>> in a merge if you have concerns...
>>>
>>> On 10 January 2012 10:08, Tom Hobbs <tv...@googlemail.com> wrote:
>>>
>>>
>>>
>>>> Let SVN do the merge, your changes might be extensive but I doubt there
>>>> has
>>>> been much movement in those files since you checked them out. So the
>>>> merge
>>>> will probably be more of a replace.
>>>>
>>>> I'm hoping to get some coding done in the next few weeks - at last! So we
>>>> might have enough changes soon for a release.
>>>>
>>>> Keep up the good work, Peter.
>>>>
>>>> Sent via mobile device, please forgive typos and spacing errors.
>>>>
>>>> On 10 Jan 2012 06:20, "Peter" <ji...@zeus.net.au> wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> The new security manager and policies are almost ready to merge back
>>>>> into
>>>>> trunk.
>>>>>
>>>>> Any svn merge tips would be much appreciated.
>>>>>
>>>>> First, I'd like to move some policy implementation classes that are at
>>>>> present public in org.apache.river.*, into package private net.jini.*
>>>>> namespaces, to reduce the public api.
>>>>>
>>>>> Not all of the code will be included, classes, like
>>>>> ConcurrentPermissions
>>>>> (and all policy cache associated classes), even though far better than
>>>>> Permissions, will be discarded, as recent developments (eliminating
>>>>> policy
>>>>> cache) have made them redundant.
>>>>>
>>>>> DelegatePermission is still there, designed to work with delegate
>>>>> wrapper
>>>>> classes that encapsulate sockets and and file handles, to enable
>>>>> removal of
>>>>> temporarily granted permissions.
>>>>>
>>>>> Example: A downloaded proxy is granted a SocketPermission to contact its
>>>>> server, if during deserialisation, the proxy modifies some public static
>>>>> fields (java.xml.* vulnerabilities ring a bell?) by replacing some
>>>>> platform
>>>>> classes with its own, it leaves some of its own proxy code on the stack
>>>>> context. The proxy after being downloaded is found to be untrusted and
>>>>> discarded.
>>>>>
>>>>> Every time the object the proxy has injected into the platform is
>>>>> accessed, it steals information and sends it back to its originating
>>>>> host.
>>>>>
>>>>> If a DelegatePermission(**SocketPermission p) is granted instead, the
>>>>> proxy
>>>>> recieves a socket that denies access when the permission is revoked,
>>>>> when
>>>>> trust can't be verified.
>>>>>
>>>>> The proxy could still perform a denial of service, by causing an out of
>>>>> memory error during deserialisation.
>>>>>
>>>>> DelegatePermission can also be used to grant temporary or limited access
>>>>> to Principals, eg after downloading 1GB, downloads are revoked and
>>>>> regranted at the next monthly cycle, something sililar could be used to
>>>>> limit writes to the file system.
>>>>>
>>>>> Obviously you'll need to buffer the input or output streams, to balance
>>>>> how often checks are performed, that is, if you choose to utilise it.
>>>>>
>>>>> A DelegateSocketFactory that can be used to encapsulate existing
>>>>> SocketFactory's will be released at a later date to enable
>>>>> DelegatePermission controlled streams and channels. Note any
>>>>> ProtectionDomains with SocketPermission will still have access to the
>>>>> same
>>>>> channel.
>>>>>
>>>>> DelegatePermission is intended to be a dynamically or runtime granted
>>>>> Permission.
>>>>>
>>>>> To function it requires a DelegateSecurityManager, each stack context
>>>>> domain must have permission either for the DelegatePermission or it's
>>>>> representative Permission.
>>>>>
>>>>> This was one motivation for a securitymanager cache, it needed to be as
>>>>> fast as possible and non blocking, unlike policy cache.
>>>>>
>>>>> Using delegates is of course optional.
>>>>>
>>>>> The other thing I was toying with was using deny as well as grant in
>>>>> policy files:
>>>>>
>>>>> Where denials would be checked first by the policy prior to checking
>>>>> grants:
>>>>>
>>>>> So you could deny a proxy access to the local network, whilst granting
>>>>> it
>>>>> access to the entire internet, with two simple policy statements.
>>>>>
>>>>> Or you could allow access to a directory, but deny access to a user
>>>>> policy
>>>>> file contained in that directory, for principal based grants.
>>>>>
>>>>> The syntax would be identical to a grant statement in policy files,
>>>>> except
>>>>> deny replaces grant.
>>>>>
>>>>> But then I realised despite the advantages, it adds complexity, because
>>>>> the deny statement could have unintended scope narrowing / widening
>>>>> consequences and Permissions like SocketPermission don't work as well as
>>>>> intended, it would be simpler to dynamically grant Permissions on an as
>>>>> needed basis.
>>>>>
>>>>> So any last remaining traces of deny must be removed.
>>>>>
>>>>> Instead of using deny in policy grants, I figure that proxy's can
>>>>> optionally include permissions.perms files under META-INF in their jar
>>>>> files as a hint to clients. By using the least priviledge model and
>>>>> limiting the GrantPermissions given to Principals administrators can
>>>>> limit
>>>>> Permissions users can grant to proxy's.
>>>>>
>>>>> The proxy developers would need to be aware they might not be granted
>>>>> all
>>>>> the permissions they'd like and offer reduced functionality by catching
>>>>> SecurityException.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Peter.
>>>>>
>>>>>
>>>>>
>>>
>>
>
>
Re: SVN Merge
Posted by Tom Hobbs <tv...@googlemail.com>.
I can try and find some time for you. Let me know what you need and I'll
do my best.
Sent via mobile device, please forgive typos and spacing errors.
On 10 Jan 2012 12:17, "Peter Firmstone" <ji...@zeus.net.au> wrote:
> Tom & Dan, thanks for the support, we're probably looking at a dry run by
> the weekend, right now I'm running the tests again, this run is expected to
> pass, I'm just checking for any regressions (same code in svn). I'll clean
> out all the redundant code, followed by some refactoring to move new public
> utility classes into package private where possible.
>
> I've you've got some time, I could use a hand to go over the new code to
> tidy up any loose ends, make sure any new public api looks right before we
> merge, so we can release quickly, once the merge is complete.
>
> At this point, the code's only been tested on sparc.
>
> Cheers,
>
> Peter.
>
> Dan Creswell wrote:
>
>> Agreed, remember --dry-run will give you a preview of what's to come
>> in a merge if you have concerns...
>>
>> On 10 January 2012 10:08, Tom Hobbs <tv...@googlemail.com> wrote:
>>
>>
>>> Let SVN do the merge, your changes might be extensive but I doubt there
>>> has
>>> been much movement in those files since you checked them out. So the
>>> merge
>>> will probably be more of a replace.
>>>
>>> I'm hoping to get some coding done in the next few weeks - at last! So we
>>> might have enough changes soon for a release.
>>>
>>> Keep up the good work, Peter.
>>>
>>> Sent via mobile device, please forgive typos and spacing errors.
>>>
>>> On 10 Jan 2012 06:20, "Peter" <ji...@zeus.net.au> wrote:
>>>
>>>
>>>
>>>> The new security manager and policies are almost ready to merge back
>>>> into
>>>> trunk.
>>>>
>>>> Any svn merge tips would be much appreciated.
>>>>
>>>> First, I'd like to move some policy implementation classes that are at
>>>> present public in org.apache.river.*, into package private net.jini.*
>>>> namespaces, to reduce the public api.
>>>>
>>>> Not all of the code will be included, classes, like
>>>> ConcurrentPermissions
>>>> (and all policy cache associated classes), even though far better than
>>>> Permissions, will be discarded, as recent developments (eliminating
>>>> policy
>>>> cache) have made them redundant.
>>>>
>>>> DelegatePermission is still there, designed to work with delegate
>>>> wrapper
>>>> classes that encapsulate sockets and and file handles, to enable
>>>> removal of
>>>> temporarily granted permissions.
>>>>
>>>> Example: A downloaded proxy is granted a SocketPermission to contact its
>>>> server, if during deserialisation, the proxy modifies some public static
>>>> fields (java.xml.* vulnerabilities ring a bell?) by replacing some
>>>> platform
>>>> classes with its own, it leaves some of its own proxy code on the stack
>>>> context. The proxy after being downloaded is found to be untrusted and
>>>> discarded.
>>>>
>>>> Every time the object the proxy has injected into the platform is
>>>> accessed, it steals information and sends it back to its originating
>>>> host.
>>>>
>>>> If a DelegatePermission(**SocketPermission p) is granted instead, the
>>>> proxy
>>>> recieves a socket that denies access when the permission is revoked,
>>>> when
>>>> trust can't be verified.
>>>>
>>>> The proxy could still perform a denial of service, by causing an out of
>>>> memory error during deserialisation.
>>>>
>>>> DelegatePermission can also be used to grant temporary or limited access
>>>> to Principals, eg after downloading 1GB, downloads are revoked and
>>>> regranted at the next monthly cycle, something sililar could be used to
>>>> limit writes to the file system.
>>>>
>>>> Obviously you'll need to buffer the input or output streams, to balance
>>>> how often checks are performed, that is, if you choose to utilise it.
>>>>
>>>> A DelegateSocketFactory that can be used to encapsulate existing
>>>> SocketFactory's will be released at a later date to enable
>>>> DelegatePermission controlled streams and channels. Note any
>>>> ProtectionDomains with SocketPermission will still have access to the
>>>> same
>>>> channel.
>>>>
>>>> DelegatePermission is intended to be a dynamically or runtime granted
>>>> Permission.
>>>>
>>>> To function it requires a DelegateSecurityManager, each stack context
>>>> domain must have permission either for the DelegatePermission or it's
>>>> representative Permission.
>>>>
>>>> This was one motivation for a securitymanager cache, it needed to be as
>>>> fast as possible and non blocking, unlike policy cache.
>>>>
>>>> Using delegates is of course optional.
>>>>
>>>> The other thing I was toying with was using deny as well as grant in
>>>> policy files:
>>>>
>>>> Where denials would be checked first by the policy prior to checking
>>>> grants:
>>>>
>>>> So you could deny a proxy access to the local network, whilst granting
>>>> it
>>>> access to the entire internet, with two simple policy statements.
>>>>
>>>> Or you could allow access to a directory, but deny access to a user
>>>> policy
>>>> file contained in that directory, for principal based grants.
>>>>
>>>> The syntax would be identical to a grant statement in policy files,
>>>> except
>>>> deny replaces grant.
>>>>
>>>> But then I realised despite the advantages, it adds complexity, because
>>>> the deny statement could have unintended scope narrowing / widening
>>>> consequences and Permissions like SocketPermission don't work as well as
>>>> intended, it would be simpler to dynamically grant Permissions on an as
>>>> needed basis.
>>>>
>>>> So any last remaining traces of deny must be removed.
>>>>
>>>> Instead of using deny in policy grants, I figure that proxy's can
>>>> optionally include permissions.perms files under META-INF in their jar
>>>> files as a hint to clients. By using the least priviledge model and
>>>> limiting the GrantPermissions given to Principals administrators can
>>>> limit
>>>> Permissions users can grant to proxy's.
>>>>
>>>> The proxy developers would need to be aware they might not be granted
>>>> all
>>>> the permissions they'd like and offer reduced functionality by catching
>>>> SecurityException.
>>>>
>>>> Regards,
>>>>
>>>> Peter.
>>>>
>>>>
>>>
>>
>>
>
>
Fwd: Re: SVN Merge
Posted by Simon IJskes - QCG <si...@qcg.nl>.
What should i or the pmc chair do in order to give 'peter_firmstone'
build permission?
Gr. Sim
-------- Original Message --------
Subject: Re: SVN Merge
Date: Fri, 13 Jan 2012 20:10:49 +1000
From: Peter Firmstone <ji...@zeus.net.au>
Reply-To: dev@river.apache.org
To: dev@river.apache.org
Can you fire it up for me again Sim?
Not working for me at present, I get:
Access Denied
peter_firmstone is missing the Build permission
Cheers & thanks,
Peter.
Simon IJskes - QCG wrote:
> On 11-01-12 13:30, Peter Firmstone wrote:
>> Hey Sim,
>>
>> Can you fire that test up for me? I don't seem to have a valid login on
>> Jenkins.
>>
>
> I did alreayd, before your last commit. A apache committer id should
> be fine.
>
>
>
>
Re: SVN Merge
Posted by Simon IJskes - QCG <si...@qcg.nl>.
Tom,
can you ask for a build permission for peter on builds@apache.org?
Gr. Sim
On 13-01-12 11:10, Peter Firmstone wrote:
> Can you fire it up for me again Sim?
>
> Not working for me at present, I get:
>
>
> Access Denied
>
> peter_firmstone is missing the Build permission
>
> Cheers & thanks,
>
> Peter.
>
>
>
> Simon IJskes - QCG wrote:
>> On 11-01-12 13:30, Peter Firmstone wrote:
>>> Hey Sim,
>>>
>>> Can you fire that test up for me? I don't seem to have a valid login on
>>> Jenkins.
>>>
>>
>> I did alreayd, before your last commit. A apache committer id should
>> be fine.
>>
>>
>>
>>
>
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: SVN Merge
Posted by Peter Firmstone <ji...@zeus.net.au>.
Can you fire it up for me again Sim?
Not working for me at present, I get:
Access Denied
peter_firmstone is missing the Build permission
Cheers & thanks,
Peter.
Simon IJskes - QCG wrote:
> On 11-01-12 13:30, Peter Firmstone wrote:
>> Hey Sim,
>>
>> Can you fire that test up for me? I don't seem to have a valid login on
>> Jenkins.
>>
>
> I did alreayd, before your last commit. A apache committer id should
> be fine.
>
>
>
>
Re: SVN Merge
Posted by Simon IJskes - QCG <si...@qcg.nl>.
On 11-01-12 13:30, Peter Firmstone wrote:
> Hey Sim,
>
> Can you fire that test up for me? I don't seem to have a valid login on
> Jenkins.
>
I did alreayd, before your last commit. A apache committer id should be
fine.
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: SVN Merge
Posted by Peter Firmstone <ji...@zeus.net.au>.
Hey Sim,
Can you fire that test up for me? I don't seem to have a valid login on
Jenkins.
Thanks,
Peter.
Peter Firmstone wrote:
> Thanks Sim.
>
> Simon IJskes - QCG wrote:
>> On 11-01-12 00:34, Peter Firmstone wrote:
>>> Simon IJskes - QCG wrote:
>>>> On 10-01-12 12:54, Peter Firmstone wrote:
>>>>>
>>>>> At this point, the code's only been tested on sparc.
>>>>
>>>> If you give the SVN url, then i will run a QA on the apache build
>>>> server.
>>
>>>
>>> https://svn.apache.org/repos/asf/river/jtsk/skunk/peterConcurrentPolicy
>>>
>>
>> You can trigger a QA run with this link:
>>
>> https://builds.apache.org/job/River-trunk-QA-ubuntu-jdk7-skunk/build?delay=0sec
>>
>>
>> Jenkins is restarting now, so i cannot start a run right now.
>>
>> Gr. Sim
>>
>
>
Re: SVN Merge
Posted by Peter Firmstone <ji...@zeus.net.au>.
Thanks Sim.
Simon IJskes - QCG wrote:
> On 11-01-12 00:34, Peter Firmstone wrote:
>> Simon IJskes - QCG wrote:
>>> On 10-01-12 12:54, Peter Firmstone wrote:
>>>>
>>>> At this point, the code's only been tested on sparc.
>>>
>>> If you give the SVN url, then i will run a QA on the apache build
>>> server.
>
>>
>> https://svn.apache.org/repos/asf/river/jtsk/skunk/peterConcurrentPolicy
>>
>
> You can trigger a QA run with this link:
>
> https://builds.apache.org/job/River-trunk-QA-ubuntu-jdk7-skunk/build?delay=0sec
>
>
> Jenkins is restarting now, so i cannot start a run right now.
>
> Gr. Sim
>
Re: SVN Merge
Posted by Simon IJskes - QCG <si...@qcg.nl>.
On 11-01-12 00:34, Peter Firmstone wrote:
> Simon IJskes - QCG wrote:
>> On 10-01-12 12:54, Peter Firmstone wrote:
>>>
>>> At this point, the code's only been tested on sparc.
>>
>> If you give the SVN url, then i will run a QA on the apache build server.
>
> https://svn.apache.org/repos/asf/river/jtsk/skunk/peterConcurrentPolicy
>
You can trigger a QA run with this link:
https://builds.apache.org/job/River-trunk-QA-ubuntu-jdk7-skunk/build?delay=0sec
Jenkins is restarting now, so i cannot start a run right now.
Gr. Sim
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: SVN Merge
Posted by Peter Firmstone <ji...@zeus.net.au>.
Simon IJskes - QCG wrote:
> On 10-01-12 12:54, Peter Firmstone wrote:
>> Tom & Dan, thanks for the support, we're probably looking at a dry run
>> by the weekend, right now I'm running the tests again, this run is
>> expected to pass, I'm just checking for any regressions (same code in
>> svn). I'll clean out all the redundant code, followed by some
>> refactoring to move new public utility classes into package private
>> where possible.
>>
>> I've you've got some time, I could use a hand to go over the new code to
>> tidy up any loose ends, make sure any new public api looks right before
>> we merge, so we can release quickly, once the merge is complete.
>>
>> At this point, the code's only been tested on sparc.
>
> If you give the SVN url, then i will run a QA on the apache build server.
>
> Gr. Sim
>
>
Thanks Sim, much appreciated, there are some tests that have regressed
at present, I'll figure out what's causing that probably later today.
https://svn.apache.org/repos/asf/river/jtsk/skunk/peterConcurrentPolicy
Cheers,
Peter.
Re: SVN Merge
Posted by Simon IJskes - QCG <si...@qcg.nl>.
On 10-01-12 12:54, Peter Firmstone wrote:
> Tom & Dan, thanks for the support, we're probably looking at a dry run
> by the weekend, right now I'm running the tests again, this run is
> expected to pass, I'm just checking for any regressions (same code in
> svn). I'll clean out all the redundant code, followed by some
> refactoring to move new public utility classes into package private
> where possible.
>
> I've you've got some time, I could use a hand to go over the new code to
> tidy up any loose ends, make sure any new public api looks right before
> we merge, so we can release quickly, once the merge is complete.
>
> At this point, the code's only been tested on sparc.
If you give the SVN url, then i will run a QA on the apache build server.
Gr. Sim
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: SVN Merge
Posted by Peter Firmstone <ji...@zeus.net.au>.
Tom & Dan, thanks for the support, we're probably looking at a dry run
by the weekend, right now I'm running the tests again, this run is
expected to pass, I'm just checking for any regressions (same code in
svn). I'll clean out all the redundant code, followed by some
refactoring to move new public utility classes into package private
where possible.
I've you've got some time, I could use a hand to go over the new code to
tidy up any loose ends, make sure any new public api looks right before
we merge, so we can release quickly, once the merge is complete.
At this point, the code's only been tested on sparc.
Cheers,
Peter.
Dan Creswell wrote:
> Agreed, remember --dry-run will give you a preview of what's to come
> in a merge if you have concerns...
>
> On 10 January 2012 10:08, Tom Hobbs <tv...@googlemail.com> wrote:
>
>> Let SVN do the merge, your changes might be extensive but I doubt there has
>> been much movement in those files since you checked them out. So the merge
>> will probably be more of a replace.
>>
>> I'm hoping to get some coding done in the next few weeks - at last! So we
>> might have enough changes soon for a release.
>>
>> Keep up the good work, Peter.
>>
>> Sent via mobile device, please forgive typos and spacing errors.
>>
>> On 10 Jan 2012 06:20, "Peter" <ji...@zeus.net.au> wrote:
>>
>>
>>> The new security manager and policies are almost ready to merge back into
>>> trunk.
>>>
>>> Any svn merge tips would be much appreciated.
>>>
>>> First, I'd like to move some policy implementation classes that are at
>>> present public in org.apache.river.*, into package private net.jini.*
>>> namespaces, to reduce the public api.
>>>
>>> Not all of the code will be included, classes, like ConcurrentPermissions
>>> (and all policy cache associated classes), even though far better than
>>> Permissions, will be discarded, as recent developments (eliminating policy
>>> cache) have made them redundant.
>>>
>>> DelegatePermission is still there, designed to work with delegate wrapper
>>> classes that encapsulate sockets and and file handles, to enable removal of
>>> temporarily granted permissions.
>>>
>>> Example: A downloaded proxy is granted a SocketPermission to contact its
>>> server, if during deserialisation, the proxy modifies some public static
>>> fields (java.xml.* vulnerabilities ring a bell?) by replacing some platform
>>> classes with its own, it leaves some of its own proxy code on the stack
>>> context. The proxy after being downloaded is found to be untrusted and
>>> discarded.
>>>
>>> Every time the object the proxy has injected into the platform is
>>> accessed, it steals information and sends it back to its originating host.
>>>
>>> If a DelegatePermission(SocketPermission p) is granted instead, the proxy
>>> recieves a socket that denies access when the permission is revoked, when
>>> trust can't be verified.
>>>
>>> The proxy could still perform a denial of service, by causing an out of
>>> memory error during deserialisation.
>>>
>>> DelegatePermission can also be used to grant temporary or limited access
>>> to Principals, eg after downloading 1GB, downloads are revoked and
>>> regranted at the next monthly cycle, something sililar could be used to
>>> limit writes to the file system.
>>>
>>> Obviously you'll need to buffer the input or output streams, to balance
>>> how often checks are performed, that is, if you choose to utilise it.
>>>
>>> A DelegateSocketFactory that can be used to encapsulate existing
>>> SocketFactory's will be released at a later date to enable
>>> DelegatePermission controlled streams and channels. Note any
>>> ProtectionDomains with SocketPermission will still have access to the same
>>> channel.
>>>
>>> DelegatePermission is intended to be a dynamically or runtime granted
>>> Permission.
>>>
>>> To function it requires a DelegateSecurityManager, each stack context
>>> domain must have permission either for the DelegatePermission or it's
>>> representative Permission.
>>>
>>> This was one motivation for a securitymanager cache, it needed to be as
>>> fast as possible and non blocking, unlike policy cache.
>>>
>>> Using delegates is of course optional.
>>>
>>> The other thing I was toying with was using deny as well as grant in
>>> policy files:
>>>
>>> Where denials would be checked first by the policy prior to checking
>>> grants:
>>>
>>> So you could deny a proxy access to the local network, whilst granting it
>>> access to the entire internet, with two simple policy statements.
>>>
>>> Or you could allow access to a directory, but deny access to a user policy
>>> file contained in that directory, for principal based grants.
>>>
>>> The syntax would be identical to a grant statement in policy files, except
>>> deny replaces grant.
>>>
>>> But then I realised despite the advantages, it adds complexity, because
>>> the deny statement could have unintended scope narrowing / widening
>>> consequences and Permissions like SocketPermission don't work as well as
>>> intended, it would be simpler to dynamically grant Permissions on an as
>>> needed basis.
>>>
>>> So any last remaining traces of deny must be removed.
>>>
>>> Instead of using deny in policy grants, I figure that proxy's can
>>> optionally include permissions.perms files under META-INF in their jar
>>> files as a hint to clients. By using the least priviledge model and
>>> limiting the GrantPermissions given to Principals administrators can limit
>>> Permissions users can grant to proxy's.
>>>
>>> The proxy developers would need to be aware they might not be granted all
>>> the permissions they'd like and offer reduced functionality by catching
>>> SecurityException.
>>>
>>> Regards,
>>>
>>> Peter.
>>>
>
>
Re: SVN Merge
Posted by Dan Creswell <da...@gmail.com>.
Agreed, remember --dry-run will give you a preview of what's to come
in a merge if you have concerns...
On 10 January 2012 10:08, Tom Hobbs <tv...@googlemail.com> wrote:
> Let SVN do the merge, your changes might be extensive but I doubt there has
> been much movement in those files since you checked them out. So the merge
> will probably be more of a replace.
>
> I'm hoping to get some coding done in the next few weeks - at last! So we
> might have enough changes soon for a release.
>
> Keep up the good work, Peter.
>
> Sent via mobile device, please forgive typos and spacing errors.
>
> On 10 Jan 2012 06:20, "Peter" <ji...@zeus.net.au> wrote:
>
>> The new security manager and policies are almost ready to merge back into
>> trunk.
>>
>> Any svn merge tips would be much appreciated.
>>
>> First, I'd like to move some policy implementation classes that are at
>> present public in org.apache.river.*, into package private net.jini.*
>> namespaces, to reduce the public api.
>>
>> Not all of the code will be included, classes, like ConcurrentPermissions
>> (and all policy cache associated classes), even though far better than
>> Permissions, will be discarded, as recent developments (eliminating policy
>> cache) have made them redundant.
>>
>> DelegatePermission is still there, designed to work with delegate wrapper
>> classes that encapsulate sockets and and file handles, to enable removal of
>> temporarily granted permissions.
>>
>> Example: A downloaded proxy is granted a SocketPermission to contact its
>> server, if during deserialisation, the proxy modifies some public static
>> fields (java.xml.* vulnerabilities ring a bell?) by replacing some platform
>> classes with its own, it leaves some of its own proxy code on the stack
>> context. The proxy after being downloaded is found to be untrusted and
>> discarded.
>>
>> Every time the object the proxy has injected into the platform is
>> accessed, it steals information and sends it back to its originating host.
>>
>> If a DelegatePermission(SocketPermission p) is granted instead, the proxy
>> recieves a socket that denies access when the permission is revoked, when
>> trust can't be verified.
>>
>> The proxy could still perform a denial of service, by causing an out of
>> memory error during deserialisation.
>>
>> DelegatePermission can also be used to grant temporary or limited access
>> to Principals, eg after downloading 1GB, downloads are revoked and
>> regranted at the next monthly cycle, something sililar could be used to
>> limit writes to the file system.
>>
>> Obviously you'll need to buffer the input or output streams, to balance
>> how often checks are performed, that is, if you choose to utilise it.
>>
>> A DelegateSocketFactory that can be used to encapsulate existing
>> SocketFactory's will be released at a later date to enable
>> DelegatePermission controlled streams and channels. Note any
>> ProtectionDomains with SocketPermission will still have access to the same
>> channel.
>>
>> DelegatePermission is intended to be a dynamically or runtime granted
>> Permission.
>>
>> To function it requires a DelegateSecurityManager, each stack context
>> domain must have permission either for the DelegatePermission or it's
>> representative Permission.
>>
>> This was one motivation for a securitymanager cache, it needed to be as
>> fast as possible and non blocking, unlike policy cache.
>>
>> Using delegates is of course optional.
>>
>> The other thing I was toying with was using deny as well as grant in
>> policy files:
>>
>> Where denials would be checked first by the policy prior to checking
>> grants:
>>
>> So you could deny a proxy access to the local network, whilst granting it
>> access to the entire internet, with two simple policy statements.
>>
>> Or you could allow access to a directory, but deny access to a user policy
>> file contained in that directory, for principal based grants.
>>
>> The syntax would be identical to a grant statement in policy files, except
>> deny replaces grant.
>>
>> But then I realised despite the advantages, it adds complexity, because
>> the deny statement could have unintended scope narrowing / widening
>> consequences and Permissions like SocketPermission don't work as well as
>> intended, it would be simpler to dynamically grant Permissions on an as
>> needed basis.
>>
>> So any last remaining traces of deny must be removed.
>>
>> Instead of using deny in policy grants, I figure that proxy's can
>> optionally include permissions.perms files under META-INF in their jar
>> files as a hint to clients. By using the least priviledge model and
>> limiting the GrantPermissions given to Principals administrators can limit
>> Permissions users can grant to proxy's.
>>
>> The proxy developers would need to be aware they might not be granted all
>> the permissions they'd like and offer reduced functionality by catching
>> SecurityException.
>>
>> Regards,
>>
>> Peter.
Re: SVN Merge
Posted by Tom Hobbs <tv...@googlemail.com>.
Let SVN do the merge, your changes might be extensive but I doubt there has
been much movement in those files since you checked them out. So the merge
will probably be more of a replace.
I'm hoping to get some coding done in the next few weeks - at last! So we
might have enough changes soon for a release.
Keep up the good work, Peter.
Sent via mobile device, please forgive typos and spacing errors.
On 10 Jan 2012 06:20, "Peter" <ji...@zeus.net.au> wrote:
> The new security manager and policies are almost ready to merge back into
> trunk.
>
> Any svn merge tips would be much appreciated.
>
> First, I'd like to move some policy implementation classes that are at
> present public in org.apache.river.*, into package private net.jini.*
> namespaces, to reduce the public api.
>
> Not all of the code will be included, classes, like ConcurrentPermissions
> (and all policy cache associated classes), even though far better than
> Permissions, will be discarded, as recent developments (eliminating policy
> cache) have made them redundant.
>
> DelegatePermission is still there, designed to work with delegate wrapper
> classes that encapsulate sockets and and file handles, to enable removal of
> temporarily granted permissions.
>
> Example: A downloaded proxy is granted a SocketPermission to contact its
> server, if during deserialisation, the proxy modifies some public static
> fields (java.xml.* vulnerabilities ring a bell?) by replacing some platform
> classes with its own, it leaves some of its own proxy code on the stack
> context. The proxy after being downloaded is found to be untrusted and
> discarded.
>
> Every time the object the proxy has injected into the platform is
> accessed, it steals information and sends it back to its originating host.
>
> If a DelegatePermission(SocketPermission p) is granted instead, the proxy
> recieves a socket that denies access when the permission is revoked, when
> trust can't be verified.
>
> The proxy could still perform a denial of service, by causing an out of
> memory error during deserialisation.
>
> DelegatePermission can also be used to grant temporary or limited access
> to Principals, eg after downloading 1GB, downloads are revoked and
> regranted at the next monthly cycle, something sililar could be used to
> limit writes to the file system.
>
> Obviously you'll need to buffer the input or output streams, to balance
> how often checks are performed, that is, if you choose to utilise it.
>
> A DelegateSocketFactory that can be used to encapsulate existing
> SocketFactory's will be released at a later date to enable
> DelegatePermission controlled streams and channels. Note any
> ProtectionDomains with SocketPermission will still have access to the same
> channel.
>
> DelegatePermission is intended to be a dynamically or runtime granted
> Permission.
>
> To function it requires a DelegateSecurityManager, each stack context
> domain must have permission either for the DelegatePermission or it's
> representative Permission.
>
> This was one motivation for a securitymanager cache, it needed to be as
> fast as possible and non blocking, unlike policy cache.
>
> Using delegates is of course optional.
>
> The other thing I was toying with was using deny as well as grant in
> policy files:
>
> Where denials would be checked first by the policy prior to checking
> grants:
>
> So you could deny a proxy access to the local network, whilst granting it
> access to the entire internet, with two simple policy statements.
>
> Or you could allow access to a directory, but deny access to a user policy
> file contained in that directory, for principal based grants.
>
> The syntax would be identical to a grant statement in policy files, except
> deny replaces grant.
>
> But then I realised despite the advantages, it adds complexity, because
> the deny statement could have unintended scope narrowing / widening
> consequences and Permissions like SocketPermission don't work as well as
> intended, it would be simpler to dynamically grant Permissions on an as
> needed basis.
>
> So any last remaining traces of deny must be removed.
>
> Instead of using deny in policy grants, I figure that proxy's can
> optionally include permissions.perms files under META-INF in their jar
> files as a hint to clients. By using the least priviledge model and
> limiting the GrantPermissions given to Principals administrators can limit
> Permissions users can grant to proxy's.
>
> The proxy developers would need to be aware they might not be granted all
> the permissions they'd like and offer reduced functionality by catching
> SecurityException.
>
> Regards,
>
> Peter.
Re: SVN Merge
Posted by Peter Firmstone <ji...@zeus.net.au>.
Greg Trasuk wrote:
> On Tue, 2012-01-10 at 01:24, Peter wrote:
>
>> The new security manager and policies are almost ready to merge back into trunk.
>>
>> Any svn merge tips would be much appreciated.
>>
>> First, I'd like to move some policy implementation classes that are at present public in org.apache.river.*, into package private net.jini.* namespaces, to reduce the public api.
>>
>>
> I think you have that backwards - implementation classes should be
> "org.apache.river.*". "net.jini.*" should be public API and core
> classes.
>
> Having said that, I see that DynamicPolicyProvider is in
> "net.jini.security.policy", and by that logic if it had package-private
> classes then they would reasonably go into the "net.jini.*" namespace.
> However I'd argue that the security policy is not "core Jini" so much as
> runtime environemnt, so I'd leave them in the "org.apache.river.*"
> namespace.
>
I did consider making DynamicPolicyProvider a skeleton class, then put
the implementation in org.apache.river, but then I realised that this
could create confusion with some of properties that need to be defined.
Another alternative is to leave DynamicPolicyProvider unchanged (how it
is currently in trunk), perhaps deprecated and put the new
implementation into a new class in org.apache.river.* and define
different configuration properties.
But these two options create additional complexity in configuration.
Since I've removed the cache from DynamicPolicyProvider, I think I can
remove the dependencies on classes in other packages that should be
package private, without placing those classes in net.jini.security.* so
that net.jini.security.policy remains largely untouched.
Regards,
Peter.
Re: SVN Merge
Posted by Greg Trasuk <tr...@stratuscom.com>.
On Tue, 2012-01-10 at 01:24, Peter wrote:
> The new security manager and policies are almost ready to merge back into trunk.
>
> Any svn merge tips would be much appreciated.
>
> First, I'd like to move some policy implementation classes that are at present public in org.apache.river.*, into package private net.jini.* namespaces, to reduce the public api.
>
I think you have that backwards - implementation classes should be
"org.apache.river.*". "net.jini.*" should be public API and core
classes.
Having said that, I see that DynamicPolicyProvider is in
"net.jini.security.policy", and by that logic if it had package-private
classes then they would reasonably go into the "net.jini.*" namespace.
However I'd argue that the security policy is not "core Jini" so much as
runtime environemnt, so I'd leave them in the "org.apache.river.*"
namespace.
> ...snip...
Cheers,
Greg.