Host foo - это клиент IBM MQ (т. Е. Соединение в режиме клиента через TCP / IP). Панель хоста - это система, в которой работает администратор очередей. Bar предоставляет разрешение (по IP-адресу) для foo на создание экземпляра объекта com.ibm.mq.MQQueueManager, но не дает разрешения на размещение foobar.
Поэтому я инкапсулирую все контакты IBM MQ в новое приложение, работающее на foo. Вместе с foobar формируется клиент-серверное приложение, использующее сокеты, где foo - это сервер, а foobar - клиент. Foo по-прежнему остается клиентом IBM MQ.
Пока что все, что я пытался сделать с foo в новом приложении (связанном с MQ), - это создать экземпляр объекта MQQueueManager. Это успешно, пока я не представлю java.lang.SecurityManager.
Локальные приложения, выполняемые с помощью команды java, например это приложение для foo, по умолчанию не запускаются с установленным SecurityManager. Теперь он запускается с установленным SecurityManager. Причина в том, чтобы контролировать доступ к этому приложению, запущенному на foo. Политика безопасности принимает подключения от foobar (java.net.SocketPermission). Это работает. Владелец foo теперь может контролировать разрешение, предоставленное foobar.
Но мы получаем некоторое вмешательство во взаимодействие между foo и bar. Помехи исходит от SecurityManager. Не запускайте с установленным SecurityManager, и foo может создать экземпляр MQQueueManager. Запустите с помощью SecurityManager, и foo зависнет в конструкторе MQQueueManager.
Foo использует эталонную реализацию политики, описанную в https://docs.oracle.com/javase/7/docs/technotes/guides/security/PolicyFiles.html
Следующее разрешение для foo приводит к зависанию конструктора MQQueueManager.
permission java.net.SocketPermission "bar", "connect, accept";
-Dcom.ibm.msg.client.commonservices.trace.status=ON
-Djava.security.debug = "access,failure"
... access denied ("java.util.PropertyPermission" "mqs.disable.all.intercept" "read") [java.security.AccessControlException] ...
... access denied ("java.util.PropertyPermission" "mqs.intercept.serializeconn" "read") [java.security.AccessControlException] ...
Версия MQ из каждого файла com.ibm.mq * .jar, имеющего файл MANIFEST.MF, кажется, 8.0.0.3.
Да, я подозревал, что этого действия «подключить» должно было быть достаточно. Проблема здесь в том, что конструктор MQQueueManager представляет собой черный ящик.
Ваш комментарий «просто для того, чтобы прояснить ситуацию», совершенно правильный. Только Foo имеет права доступа к MQ (на панели). Я не хочу нарушать дух этого, поэтому я оставляю за владельцем foo контроль над расширением (абстрактного) доступа к foobar.
Просматривая предоставленную мной ссылку, я не вижу упомянутых конкретных свойств, но я бы предложил добавить это и повторить попытку permission java.util.PropertyPermission "mqs.*","read";.
Наконец-то вчера поздно вечером прошел тест. Я не заметил, что PropertyPermission «mqs. *» Не был указан в предоставленной вами ссылке, поэтому спасибо, что указали на это. Я начинаю смотреть на проблемы, которые мы еще не решили. Жду изменения моего вопроса или более информативного комментария в ближайшее время.
Вы используете AMS?
«Проблемы, которые мы еще не решили», в основном оказались чрезмерным объемом вывода из-за непреднамеренного включения трассировки. Конструктор MQQueueManager больше не зависает при установке SecurityManager. permission java.util.PropertyPermission "mqs.*","read"; не нужен. Оставшаяся (незначительная) проблема SecurityManager не связана с MQ, поэтому она неуместна в этой теме.
Я не уверен, что используется IBM MQ Advanced Message Security (AMS).
Единственная ссылка, которую я нашел на свойства «mqs. *», Относится к AMS для MQ v7.0.1, когда AMS был отдельным продуктом. Возможно, он запрашивает некоторые свойства, чтобы узнать, используется ли он, поэтому отсутствие разрешения ничего не повредит, если вы не используете эту функцию.




But we’re getting some interference in the interaction between foo and bar. The interference is coming from the SecurityManager. Don’t run with a SecurityManager installed and foo can instantiate MQQueueManager. Run with a SecurityManager and foo hangs in the MQQueueManager constructor.
Это просто странно. Где в документации MQ говорится об использовании Java SecurityManager. Кто-то дал вам неверную информацию. Кроме того, вы не выполняете безопасность MQ с помощью SecurityManager.
The following permission on foo results in the MQQueueManager constructor hanging. permission java.net.SocketPermission "bar", "connect, accept";
Почему вы ограничиваете возможности клиентской библиотеки MQ? Если он не может прослушивать и разрешать TCP-соединение, он не будет работать. Просто удалите эту строку.
Где в документации MQ сказано, что я не могу использовать Java SecurityManager для ограничения доступа к foo? Поймите, что foobar ничего не должен знать о IBM MQ, просто есть некоторые очереди, доступные в foo. Я не хочу каким-либо образом ограничивать возможности клиентской библиотеки MQ. Действие «разрешить» подразумевается, когда присутствует любое из других действий. Действие «прослушивание» имеет смысл только при использовании с «localhost» и означает возможность привязки к указанному порту. Удаление этой строки полностью отрицает даже действия «подключить» и «принять».
Я создаю клиентские приложения Java / MQ более 15 лет. Я создал их сотни, самая известная из них - MQ Visual Edit. Ни разу за все эти годы я не подумал, позвольте мне применить безопасность с помощью класса SecurityManager. Правильный способ обеспечения безопасности - использовать диспетчер очередей CONNAUTH (для аутентификации), CHLAUTH (для фильтрации) и setmqaut (для авторизации).
IBM MQ v8 KC имеет страницу «Запуск классов IBM MQ для приложений Java под управлением Java Security Manager».
На этой странице указано, что касается клиентских подключений MQ:
//For the client transport type. permission java.net.SocketPermission "*","connect,resolve";
Единственное, что я заметил, - это отсутствие пробелов в приведенном выше примере по сравнению с тем, что вы опубликовали, также вам не нужно будет предоставлять разрешение accept, и я также отметил в документации sun, что resolve подразумевается с connect, поэтому в этом нет особой необходимости.
Есть много других настроек, связанных с другими разрешениями, которые могут вам понадобиться, поэтому я бы посоветовал просмотреть приведенную выше страницу для получения дополнительных сведений.
Вы можете взять трассировку IBM MQ Classes for Java, используя следующее системное свойство java:
-Dcom.ibm.msg.client.commonservices.trace.status=ON
По умолчанию трассировка будет выводиться в файл в текущем каталоге с именем mqjms_%PID%.trc, где %PID% заменяется идентификатором процесса вашего java-процесса.
Если вы хотите указать другое имя или путь к файлу, вы можете добавить следующее системное свойство java:
-Dcom.ibm.msg.client.commonservices.trace.outputName=/tmp/x/y/z/mqjms_%PID%.trc
Пример команды с обоими:
java -Dcom.ibm.msg.client.commonservices.trace.status=ON -Dcom.ibm.msg.client.commonservices.trace.outputName=mqjms_%PID%.trc SomeJavaApp
Может быть полезна трассировка диспетчера безопасности Java, вы можете включить ее, добавив следующее системное свойство Java:
-Djava.security.debug = "access,failure"
Все попытки принять этот ответ или пометить его как полезный приводят к сообщению об ошибке от Stack Overflow. «Произошла ошибка - повторите запрос».
Чтобы прояснить ситуацию, я понимаю из вашего вопроса, что вы пытаетесь заблокировать соединения в своем приложении из другого приложения по IP-адресу или имени хоста с помощью SecurityManager, вторично по отношению к этому, вы должны разрешить своему приложению подключаться в качестве клиента MQ к диспетчер очереди, это не дополнительная безопасность, которую вы пытаетесь добавить для своего MQ-клиента к соединению MQ-сервера.