Как нормально настроить политику безопасности в Tomcat 6

Я использую Tomcat 6.0.24, как упаковано для Кармической Ubuntu. Политика безопасности по умолчанию пакета Tomcat Ubuntu является довольно строгой, но кажется простой. В /var/lib/tomcat6/conf/policy.d, существует множество файлов, которые устанавливают политику по умолчанию.

Стоящий замечания в запуске:

• Я не изменил установку кота запаса вообще - никакие новые банки в ее общий каталог (каталоги) lib, нет server.xml изменения, и т.д. Вставляя .war файл webapps каталог является единственным действием развертывания.
• веб-приложение я развертываю сбои с тысячами отказов в доступе под этой политикой по умолчанию (как сообщается журналу благодаря -Djava.security.debug="access,stack,failure" системное свойство).
• выключение менеджера безопасности полностью не приводит ни к каким ошибкам вообще и надлежащей функциональности приложения

То, что я хотел бы сделать, добавляет специализированный файл политики безопасности к policy.d каталог, который, кажется, методические рекомендации. Я добавил это к policy.d/100myapp.policy (как начальная точка - я хотел бы в конечном счете обрезать назад данные разрешения к только, в чем приложение на самом деле нужно):

grant codeBase "file:${catalina.base}/webapps/ROOT.war" {
  permission java.security.AllPermission;
};

grant codeBase "file:${catalina.base}/webapps/ROOT/-" {
  permission java.security.AllPermission;
};

grant codeBase "file:${catalina.base}/webapps/ROOT/WEB-INF/-" {
  permission java.security.AllPermission;
};

grant codeBase "file:${catalina.base}/webapps/ROOT/WEB-INF/lib/-" {
  permission java.security.AllPermission;
};

grant codeBase "file:${catalina.base}/webapps/ROOT/WEB-INF/classes/-" {
  permission java.security.AllPermission;
};

Отметьте метание попытки найти право codeBase объявление. Я думаю, что это вероятно моя фундаментальная проблема.

Так или иначе вышеупомянутое (действительно только первые два предоставления, кажется, имеют любой эффект), почти работает: тысяч отказов в доступе не стало, и со мной оставляют всего один. Соответствующее отслеживание стека:

java.security.AccessControlException: access denied (java.io.FilePermission /var/lib/tomcat6/webapps/ROOT/WEB-INF/classes/com/foo/some-file-here.txt read)
  java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
  java.security.AccessController.checkPermission(AccessController.java:546)
  java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
  java.lang.SecurityManager.checkRead(SecurityManager.java:871)
  java.io.File.exists(File.java:731)
  org.apache.naming.resources.FileDirContext.file(FileDirContext.java:785)
  org.apache.naming.resources.FileDirContext.lookup(FileDirContext.java:206)
  org.apache.naming.resources.ProxyDirContext.lookup(ProxyDirContext.java:299)
  org.apache.catalina.loader.WebappClassLoader.findResourceInternal(WebappClassLoader.java:1937)
  org.apache.catalina.loader.WebappClassLoader.findResource(WebappClassLoader.java:973)
  org.apache.catalina.loader.WebappClassLoader.getResource(WebappClassLoader.java:1108)
  java.lang.ClassLoader.getResource(ClassLoader.java:973)

Я довольно убежден, что фактический файл, это инициировало отказ, не важен - это - просто некоторый файл свойств, который мы проверяем на дополнительные параметры конфигурации. То, что интересно, то, что:

1. это не существует в этом контексте
2. то, что файл не существует, заканчивает тем, что бросило исключение безопасности, а не java.io.File.exists() просто возвращая false (хотя я предполагаю, что это - просто вопрос семантики разрешения чтения).

Другое обходное решение (помимо просто отключения менеджера безопасности у кота) должно добавить открытое разрешение к моему файлу политики:

grant {
  permission java.security.AllPermission;
};

Я предполагаю, что это функционально эквивалентно выключению менеджера безопасности.

Я предполагаю, что должен добираться codeBase объявление в моих предоставлениях тонко неправильно, но я не вижу его в данный момент.