<param name="jnlp_href" value="permissions.jnlp">
<!--....-->
<security>
<all-permissions/>
</security>
AccessControlException createClassLoader
Мой апплет использует собственный загрузчик классов и драйвер для работы с ms sql сервер. Когда вызывается super() в теле конструктора загрузчика классов я получаю
...однако браузер намертво 'виснет'.
Далее, я подписал JAR архив с апплетом по сл. шаблону
Цитата:
java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "createClassLoader")
Пробовал через JNLP
Код:
...однако браузер намертво 'виснет'.
Далее, я подписал JAR архив с апплетом по сл. шаблону
Цитата:
keytool -genkey -keystore myKeyStore -alias me
keytool -selfcert -keystore myKeyStore -alias me
jarsigner -keystore myKeyStore jarfile.jar me
keytool -selfcert -keystore myKeyStore -alias me
jarsigner -keystore myKeyStore jarfile.jar me
...однако я всё равно получаю
Цитата:
java.security.AccessControlException
Пожалуйста, не советуйте модифицировать \jre\lib\security\java.policy потому, что это громоздкое (если вообще возможное) и недружественное решение.
P.S. если отредактировать java.policy то всё работает.
- 234234 от mike_new, 16 января 2012 года
- 3523452345 от , 16 января 2012 года
Твой сертификат добавлен в доверенные? Сторонние библиотеки подписаны?
Цитата: arrjj
Твой сертификат добавлен в доверенные? Сторонние библиотеки подписаны?
Да, JDBC драйвер подписанный. А что значит 'доверенный'? Это когда браузер запрашивает разрешение на использование плагина? Да, я разрешил. В своем посте я указал, как именно подписывался архив.
Очень нужна помощь - я уже все Java-форумы облазил, и нигде не получил дельного совета!
<link>
Цитата:
If your enemy compiled the class and asked you to load it (java MyLoader2 MaliciousApp), this code would delete the file personal-data from your system. This is just one example of security concerns associated with class loaders; try to think of others. For example, what happens if an application is able to load its own class loader, or open socket connections to remote hosts? These are actually some of the security issues that applets (and therefore class loaders implemented by web browsers) are concerned with.
Цитата:
One way to protect against such attacks is by using a security manager, which is not automatically installed when an application is running. If you wish to apply the same security policy to an application found on the local file system as to downloaded applets, you can invoke the Java interpreter with the default security manager as follows: prompt> java -Djava.security.manager MyLoader2
This, however, will give you the following output: AccessControlException is thrown
This, however, will give you the following output: AccessControlException is thrown
Цитата:
Now, since there is a security manager in place, the URLClassLoader constructor will first call the security manager's checkCreateClassLoader() to ensure creation of a class loader is allowed. The default security manager, however, doesn't allow your application to create its own class loader. [COLOR="royalblue"]One possible solution is to define a security policy[/COLOR]. The Java environment will adhere to run-time restrictions; therefore, you can devise an application-level security policy for use with your application. Such a security policy allows you to state, using grant clauses, what sorts of actions a Java program can and cannot perform. Code V shows a sample security policy that allows code loaded from the local file system to do anything. Using this policy, the application is allowed to create its own class loader. A security policy can be specified on the command line using the -Djava.security.policy=policy-name command line argument.
Код:
grant codeBase "file:/-" {
permission java.security.AllPermission;
};
permission java.security.AllPermission;
};
Я там уже был - см. мое первое сообщение.
Задавать permissions jvm на клиентской машине посредством того же апплета, для которого это всё 'заваривалось' мне кажется нереальным.
<link>
Цитата:
A security manager is a Java virtual machine (VM) object that implements a security policy. By default, the Java 2® platform software provides a security manager that disallows all access to local system resources apart from read and write access to the directory and its subcirectories where the program is invoked.
[COLOR="royalblue"] You can extend the default security manager to implement customized verifications and approvals for applets [/COLOR]and applications, but the implementation must include the appropriate access verification code for every checkXXX method you override. If you do not include this code, no access verfication check happens, and your code breaches the system security policy.
[COLOR="royalblue"] You can extend the default security manager to implement customized verifications and approvals for applets [/COLOR]and applications, but the implementation must include the appropriate access verification code for every checkXXX method you override. If you do not include this code, no access verfication check happens, and your code breaches the system security policy.
Я так понял из примера, что я могу положить в архив с апплетом, в файл *.properties какой нибудь пароль, чтобы соблюсти безопасность, а затем наследовавшись от SecurityManager, перегрузить соответствующий метод?
А разве назначение SecurityManager' а не требует особых разрешений? Это же замкнутый круг! К тому же, в перегруженных методах вызывается checkPermission, который по-моему, тоже особо контролируется vm.
К тому же неясно, куда в апплет(JAR) пихать policy-файл и как запускать апплет с параметрами. Вернее, не апплет, а jre.
Однако, с этим ещё можно разобраться, а вот с назначением SecurityManager' а дела обстоят гораздо хуже, по-моему.