river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tom Hobbs" <tom.ho...@sucfin.com>
Subject River Tests | Loading the policies
Date Tue, 09 Dec 2008 15:39:43 GMT
Hi all, 

 

Can anyone offer me some help?

 

Whilst trying to port the tests into the main source directory I find
that the whatever-it-is is not loading the necessary policy and
permissions that the tests need.  This means that in order to progress
I've had to introduce a very nasty hack whereby all policy checking is
short circuited and everything is allowed.  I'm at the stage now where I
want to go back and remove that hack and replace it with the appropriate
mechanism, but I just don't seem to be able to find it.

 

In short my question is; does anyone know what the "whatever-it-is" is
that loads the policy and permissions when running the tests?  I've been
stepping and sys-outing through the code and the some of the things I've
managed to find are;

 

-          dynamic-policy.properties

-          net.jini.security.policy.DynamicPolicyProvider

-          com.sun.jini.qa.harness.MergedPolicyProvider

 

The above properties file seems to get read but the two classes don't
seem to be executed at all.  I've been looking in the unmodified code
also and haven't been able to work out how it works there either.

 

I've also found AbstractServiceAdmin.getServicePolicyFile() which does
get called and does managed to find the right policy file, but I can't
find out where the policy file it finds gets used.  However, I'm
thinking that there must be some additional permissions set in other
places, for example, the following needs to be set;

 

PropertyPermission "user.dir" "read,write"

 

As well as a huge number of others, which are presumably default ones
which I only know about because of my proliferation of sysouts.  And I
can't find out where these are getting set.

 

Can anyone offer me some pointers or reference to a document that I've
missed somewhere please?

 

Thanks.

 

Tom

 

NB: This is the hack in TestBase.setup(QAConfig config);

 

System.setSecurityManager(new RMISecurityManager() {

    public void checkPropertyAccess(String prop) {}

    public void checkPermission(Permission p) {}

});

 

Now you can see why I'm so eager to remove it.

 

www.sucden.co.uk
Sucden (UK) Limited, 5 London Bridge Street, London SE1 9SG
Telephone +44 20 7940 9400
 
Registered in England no. 1095841
VAT registration no. GB 446 9061 33
Authorised and Regulated by the Financial Services Authority (FSA) and entered in the FSA
register under no. 114239

This email, including any files transmitted with it, is confidential and may be privileged.
It may be read, copied and used only by the intended recipient. If you are not the intended
recipient of this message, please notify postmaster@sucden.co.uk immediately and delete it
from your computer system.

We believe, but do not warrant, that this email and its attachments are virus-free, but you
should check. 

Sucden (UK) Ltd may monitor traffic data of both business and personal emails. By replying
to this email, you consent to Sucden’s monitoring the content of any emails you send to
or receive from Sucden. Sucden is not liable for any opinions expressed by the sender where
this is a non-business email.
The contents of this e-mail do not constitute advice and should not be regarded as a recommendation
to buy, sell or otherwise deal with any particular investment.
This message has been scanned for viruses by Mimecast.
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message