CDV ❯ default java security policy under Websphere AS doesn't jive with terracotta
-
Bug
-
Status: Closed
-
2 Major
-
Resolution: Fixed
-
-
-
foshea
-
Reporter: teck
-
May 04, 2007
-
0
-
Watchers: 0
-
September 24, 2007
-
June 18, 2007
Description
There might be more examples, but hte default security policy in place under WAS get’s tripped in at least two place in our code base
1) java.security.AccessControlException: Access denied (java.io.FilePermission /home/teck/adapted/… – If you turn on -Dtc.classloader.writeToDisk=true
2) Reading the *.xsb resource files out of tc.jar fails – these are some compiled bits of our xmlBeans stuff I think
The only known solution at the moment is to change the policy file, commenting out all the defaults and adding just this:
grant { permission java.security.AllPermission; };
Comments
Geert Bevin 2007-05-04
Fiona OShea 2007-05-31
REsearch what user needs to to, doc it if necessary, add as known issue if necessary.
Nathaniel Harward 2007-06-12
This is documentation only, and should be part of DOC-193:
In the file <WAS_HOME>/profiles/<PROFILE_NAME>/properties/server.policy the following needs to be added:
grant codeBase “file:<TC_INSTALL_DIR>/lib/-“ { permission java.security.AllPermission; };
grant codeBase “file:<TC_INSTALL_DIR>/lib/dso-boot/-“ { permission java.security.AllPermission; }
The variables <WAS_HOME>, <PROFILE_NAME> and <TC_INSTALL_DIR> all must have full paths, of course.
Nathaniel Harward 2007-06-18
Handled as part of DOC-193.
Fiona OShea 2007-09-24
verified that docs are updated
I don’t think there’s much that can be done for that besides granting the permissions. This used to be common policy in enterprise application servers. Glassfish even started out like this until they got too many wind from other projects. One thing that can be done is signing the TC jar I think and only granting these permissions to the signature key or so. I suppose that this would still make the most paranoia of sysadmins happy.