views:

127

answers:

1

We are trying to use SecurityManager with Resin 3.1.9 and run into the following problem: CodeSource.getLocation() returns null for compiled JSPs.

This means that we cannot use a specific codebase in grant clause in our policy file, for example:

grant codeBase "file:/path_to_resin/runtime/work/-" {
OR grant codeBase "file:/path_to_resin/webapp/JSP-source/-" {
  //...some jsp-specific permissions
};

Instead, we have to use a universal grant clause:

grant  {
  //..some jsp-specific permissions. Unfortunately, these will be applied
  //to all code!!!
};

Is there a way to make JSPs have a proper CodeSource? We'd like to restrict the permissions of third-party libraries, but give permissions to our own JSPs. If we cannot specify JSPs in the policy file, we might not be able to do this, or what do you think?

EDIT: We deploy JSPs as-is, so don't recompile them. That might have something to do with the problem.

A: 

I got an answer through the Resin mailing list and thought that I post it here too:

It seems that Resin 3 has a bug with this and there's now an issue for it. Basically the way that we tried should work, or at least it works on Resin 2. So, this should work:

grant codeBase "file:/path_to_resin/runtime/work/-" {
  //...some jsp-specific permissions
};

The dev lead for Resin said this: "Well, the security manager kills performance, so we generally discourage it." We might have to reconsider if it's reasonable to use SecurityManager at all. See my other question Should I use Security Manager in Java web applications? for more discussion on the topic.

Kaitsu