Hi, Dan.
I'm looking into the patch you contributed with
https://issues.apache.org/jira/browse/TUSCANY-2290. There is one issue
catching my eyes. We have samples in Tuscany today which use some technology
APIs, for example, to start the ActiveMQ JMS broker. To run these samples
with Java2 security enabled, we have to surround some of the calls with
privileged block. That seems to complicate/pollute the samples. Should we
leave these samples as-is without supporting Java2 security (or grant
permissions to the sample code directly with a policy file)?
Thanks,
Raymond
--------------------------------------------------
From: "Dan Becker" <[EMAIL PROTECTED]>
Sent: Friday, May 02, 2008 7:29 AM
To: "tuscany-dev" <[email protected]>
Subject: More Java security fixes on the way
FYI, so every one is aware of recent Tuscany security changes and for your
comments. Over the last few weeks I have been making fixes to the Tuscany
core in order to make the code a bit safer with Java 2 security enabled.
There are many instances in which we want Tuscany code to perform some
privileged action (such as read a system property or write a file to the
file system), yet we do not want client code to have this ability.
There are over 300 Tuscany calls to privileged Java APIs which may throw
some sort of security exception if proper access is not granted. Since
there are so many APIs, I have have been issuing patches in smaller
increments. This makes the patch easier to review, commit, and reverse if
there is a problem.
Following is a list of past changes related to security.
TUSCANY-2108 - Enabled Simple Calculator to run with security on
TUSCANY-2227 - Enabled ITests to run with secuirty on
TUSCANY-2030 - Enabled Simple Caclulator to run on WebSphere
Expect a few JIRAs in the next weeks to enable the demos, samples, and
vtests to run with security on. And then I would like to make a maven
profile that allows a user to test with security on or off.
If you have any other ideas related to Java 2 security, I encourage you to
mention them here.
--
Thanks, Dan Becker
