Я знаю, что это старый вопрос.Я публикую это, так как это может помочь некоторым людям.
Нам нужно было разрешить конечным пользователям загружать скрипты Groovy и выполнять их как часть веб-приложения (что делает много других вещей).Мы были обеспокоены тем, что в этих скриптах Groovy некоторые пользователи могут пытаться читать файлы из файловой системы, читать свойства системы, вызывать System.exit () и т. Д.
Я изучил http://mrhaki.blogspot.com/2014/04/groovy-goodness-restricting-script.html, ноэто не помешает опытному разработчику Groovy обойти проверки, на что указывали другие пользователи в других статьях.
Затем я попытался заставить работать http://www.sdidit.nl/2012/12/groovy-dsl-executing-scripts-in-sandbox.html, но настройка диспетчера безопасности и реализации политики во время выполнения сделалане работа для меня.Я продолжал сталкиваться с проблемами во время запуска сервера приложений и доступа к веб-странице.Казалось, что к тому времени, когда реализация политики вступила в силу, было уже слишком поздно, и «CodeSources» (на языке Java-говорить) уже взял свои параметры доступа из файла политики Java по умолчанию.
Затем я наткнулсяпревосходный технический документ Теда Ньюарда (http://www.tedneward.com/files/Papers/JavaPolicy/JavaPolicy.pdf)), который довольно убедительно объяснял, что наилучшим подходом (для моего случая использования) было установить реализацию политики при запуске JVM (а не динамически позже).
Ниже приведен подход, который работал для меня (который объединяет подходы Рене и Теда). Кстати: мы используем Groovy 2.3.10.
В [JDK_HOME] / jre / lib / security / java.security file, установите значение " policy.provider " равным "com.yourcompany.security.MySecurityPolicy".
Создайте класс MySecurityPolicy:
import java.net.MalformedURLException;
import java.net.URL;
import java.security.AllPermission;
import java.security.CodeSource;
import java.security.PermissionCollection;
import java.security.Permissions;
import java.security.Policy;
import java.util.HashSet;
import java.util.Set;
public class MySecurityPolicy extends Policy {
private final Set<URL> locations;
public MySecurityPolicy() {
try {
locations = new HashSet<URL>();
locations.add(new URL("file", "", "/groovy/shell"));
locations.add(new URL("file", "", "/groovy/script"));
} catch (MalformedURLException e) {
throw new IllegalStateException(e);
}
}
@Override
public PermissionCollection getPermissions(CodeSource codeSource) {
// Do not store these in static or instance variables. It won't work. Also... they're cached by security infrastructure ... so this is okay.
PermissionCollection perms = new Permissions();
if (!locations.contains(codeSource.getLocation())) {
perms.add(new AllPermission());
}
return perms;
}
}
Создайте папку MySecurityPolicy и поместите ее в папку [JDK_HOME] / jre / lib / ext.
Добавьте " -Djava.security.manager " в параметры запуска JVM. Выне нужно предоставлять cuСом охранник.По умолчанию работает нормально.
Опция "-Djava.security.manager" включает Java Security Manager для всего приложения.Приложение и все его зависимости будут иметь «AllPermission» и, следовательно, будут иметь возможность делать все что угодно.
Скрипты Groovy запускаются под «/ groovy / shell» и «/ groovy / script» «CodeSources».Они не обязательно являются физическими каталогами в файловой системе.Приведенный выше код не дает сценариям Groovy каких-либо разрешений.
Пользователи по-прежнему могут выполнять следующие действия:
Вы можете добавить следующее (динамически во время выполнения) к началу каждого скрипта перед передачей его наОболочка Groovy для выполнения:
@ThreadInterrupt
import groovy.transform.ThreadInterrupt
@TimedInterrupt(5)
import groovy.transform.TimedInterrupt
Они объяснены в http://www.jroller.com/melix/entry/upcoming_groovy_goodness_automatic_thread
Первый обрабатывает "Thread.currentThread (). interrupt ()" немного более изящно (но этоне мешает пользователю прерывать поток).Возможно, вы могли бы использовать AST для предотвращения прерываний в некоторой степени.В нашем случае это не является большой проблемой, поскольку каждое выполнение скрипта Groovy выполняется в своем собственном потоке, и если плохие актеры хотят убить свой собственный поток, они могут выбить себя.
Второй предотвращает бесконечный цикл ввремя ожидания всех сценариев составляет 5 секунд.Вы можете настроить время.
Обратите внимание, что я заметил снижение производительности во время выполнения скрипта Groovy, но не заметил существенного снижения производительности в остальной части веб-приложения.
Надеюсь, это поможет.