В настоящее время я использую экземпляр БД derby, созданный из версии 10.13.1.1.
Я подключаюсь через сетевой режим (startNetworkServer), работающий на сервере Redhat.
Я хочу обновить до версии 10.14.2.0
Тем не менее, при попытке подключиться к обновленной базе данных я получаю сообщение об ошибке "java.io.FilePermission", в котором отказано в доступе.
Подробнее:
Я пошел и загрузил обе версии 10.13.1.1 и 10.14.2.0 на рабочий стол Windows.
Резервная копия базы данных создается с помощью следующей команды: SYSCS_UTIL.SYSCS_BACKUP_DATABASE
Я скопировал эту резервную копию в папки 10.13 и 10.14.
Начиная с моей текущей версии (13), я запускаю сетевой сервер, а затем использую ij для подключения к базе данных. Это отлично работает, и я могу видеть таблицы. Это подтверждает, что моя резервная копия в порядке.
connect 'jdbc:derby://localhost:1527/c:\Temp\13\database;create=false';
Затем я запускаю свой сетевой сервер с 14 версиями, а затем перехожу к 14-му ij. Когда я пытаюсь подключиться к резервной копии:
connect 'jdbc:derby://localhost:1527/c:\Temp\14\database;create=false';
Я получаю файл Ошибка доступа:
ОШИБКА XJ001: ошибка SQL DERBY: ОШИБКА КОДА: 0, SQLSTATE: XJ001, SQLERRMC: java.security.AccessControlException
доступ запрещен («java.io.FilePermission», «C: \ Temp \ update_derby \ threatadvisor», «чтение»)
XJ001.U
Достаточно справедливо, я предполагаю, что это потому, что я пытаюсь подключиться к более старой версии, не запустив параметр upgrade = true. Когда я удаляю параметр создания и добавляю параметр обновления, он по-прежнему завершается ошибкой с той же проблемой.
Хорошо, возможно, я не могу обновить БД через сетевой сервер, и мне нужно напрямую подключиться к БД. Из моего приложения я использую следующую строку подключения:
jdbc:derby:C:/Temp/14/database;upgrade=true;
Приложение имеет jar версии 14 на пути к классам, поэтому следует использовать его и обновить. Что и происходит, приложение запускается нормально, и я вижу все данные. Откуда я знаю, что он обновлен? Потому что я попытался подключиться к этой 14 базе данных, используя 13 сетевых серверов и ij, и это не удалось (как и ожидалось из-за версии).
Так что я все сделал правильно? Нет, я еще раз пытаюсь подключиться к этой обновленной базе данных через сетевой сервер, используя ij, и я снова получаю проблему java.io.FilePermission.
Я вошел и убедился, что фактические разрешения ОС для папок и файлов в папке «база данных» не только для чтения. Ни один И все же это ошибки.
Я даже пытался запустить 14 сетевых серверов на redhat box (на другом порту) и пытался подключиться к этой БД через ij, и даже там я получаю проблему с разрешением файла.
Я действительно в растерянности относительно того, что делать дальше. Пожалуйста, помогите!
К вашему сведению, полный выпуск из файла derby.log:
Вт 11 Июн 12:04:15 AEST 2019: Сетевой сервер Apache Derby - 10.14.2.0 - (1828579) запущен и готов к приему соединений через порт 1527
Вторник, 11 июня 12:04:28 AEST 2019 Тема [DRDAConnThread_2,5, main] Начало действия по очистке
java.security.AccessControlException: доступ запрещен («java.io.FilePermission», «C: \ Temp \ 14 \ database», «чтение»).
в java.security.AccessControlContext.checkPermission (AccessControlContext.java:472)
в java.security.AccessController.checkPermission (AccessController.java:884)
at java.lang.SecurityManager.checkPermission (SecurityManager.java:549)
at java.lang.SecurityManager.checkRead (SecurityManager.java:888)
в java.io.File.exists (File.java:814)
в java.io.WinNTFileSystem.canonicalize (WinNTFileSystem.java:434)
в java.io.File.getCanonicalPath (File.java:618)
в org.apache.derby.impl.io.DirStorageFactory.doInit (неизвестный источник)
at org.apache.derby.impl.io.BaseStorageFactory.init (неизвестный источник)
на org.apache.derby.impl.io.DirStorageFactory.init (неизвестный источник)
в org.apache.derby.impl.services.monitor.StorageFactoryService.privGetStorageFactoryInstance (неизвестный источник)
на org.apache.derby.impl.services.monitor.StorageFactoryService.access $ 400 (неизвестный источник)в org.apache.derby.impl.services.monitor.StorageFactoryService $ 12.run (неизвестный источник)
в org.apache.derby.impl.services.monitor.StorageFactoryService $ 12.run (неизвестный источник)
at java.security.AccessController.doPrivileged (собственный метод)
в org.apache.derby.impl.services.monitor.StorageFactoryService.getCanonicalServiceName (Неизвестный источник)
в org.apache.derby.impl.services.monitor.BaseMonitor.findProviderAndStartService (неизвестный источник)
в org.apache.derby.impl.services.monitor.BaseMonitor.startPersistentService (неизвестный источник)
в org.apache.derby.iapi.services.monitor.Monitor.startPersistentService (Неизвестный источник)
at org.apache.derby.impl.jdbc.EmbedConnection $ 4.run (неизвестный источник)
at org.apache.derby.impl.jdbc.EmbedConnection $ 4.run (неизвестный источник)
at java.security.AccessController.doPrivileged (собственный метод)
в org.apache.derby.impl.jdbc.EmbedConnection.startPersistentService (неизвестный источник)
в org.apache.derby.impl.jdbc.EmbedConnection.bootDatabase (неизвестный источник)
в org.apache.derby.impl.jdbc.EmbedConnection. (Неизвестный источник)
на org.apache.derby.jdbc.InternalDriver $ 1.run (неизвестный источник)
на org.apache.derby.jdbc.InternalDriver $ 1.run (неизвестный источник)
at java.security.AccessController.doPrivileged (собственный метод)
в org.apache.derby.jdbc.InternalDriver.getNewEmbedConnection (неизвестный источник)
на org.apache.derby.jdbc.InternalDriver.connect (неизвестный источник)
на org.apache.derby.jdbc.InternalDriver.connect (неизвестный источник)
на org.apache.derby.jdbc.EmbeddedDriver.connect (неизвестный источник)
в org.apache.derby.impl.drda.Database.makeConnection (неизвестный источник)
в org.apache.derby.impl.drda.DRDAConnThread.getConnFromDatabaseName (неизвестный источник)
в org.apache.derby.impl.drda.DRDAConnThread.verifyUserIdPassword (неизвестный источник)
в org.apache.derby.impl.drda.DRDAConnThread.parseSECCHK (неизвестный источник)
в org.apache.derby.impl.drda.DRDAConnThread.parseDRDAConnection (неизвестный источник)
в org.apache.derby.impl.drda.DRDAConnThread.processCommands (неизвестный источник)
на org.apache.derby.impl.drda.DRDAConnThread.run (неизвестный источник)
Действие очистки завершено
РЕДАКТИРОВАТЬ 1
Теперь пытаемся настроить файл security.policy согласно этому руководству . Однако после создания нового файла политики на основе шаблона в демонстрационном каталоге мы даже не можем получить дерби, чтобы забрать наш файл.
Когда мы пытаемся запустить:
java -classpath "C:\Temp\14\lib\derby.jar;C:\Temp\14\lib\derbynet.jar;C:\Temp\14\lib\derbyclient.jar;C:\Temp\14\lib\derbytools.jar;C:\Temp\14\lib\derbyoptionaltools.jar" -Djava.security.manager -Djava.security.policy=C:\Temp\14\server.policy org.apache.derby.drda.NetworkServerControl start
Мы получаем следующую ошибку:
java.security.AccessControlException: доступ запрещен org.apache.derby.security.SystemPermission ("engine", "usederbyinternals")
в java.security.AccessControlContext.checkPermission (AccessControlContext.java:472)
в java.security.AccessController.checkPermission (AccessController.java:884)
в org.apache.derby.iapi.security.SecurityUtil.checkDerbyInternalsPrivilege (неизвестный источник)
на org.apache.derby.iapi.services.monitor.Monitor.getMonitorLite (неизвестный источник)
в org.apache.derby.iapi.services.property.PropertyUtil $ 2.run (неизвестный источник)
в org.apache.derby.iapi.services.property.PropertyUtil $ 2.run (неизвестный источник)
at java.security.AccessController.doPrivileged (собственный метод)
в org.apache.derby.iapi.services.property.PropertyUtil.getMonitorLite (неизвестный источник)
в org.apache.derby.iapi.services.property.PropertyUtil.getSystemProperty (Неизвестный источник)
в org.apache.derby.iapi.services.property.PropertyUtil.getSystemProperty (Неизвестный источник)
в org.apache.derby.impl.drda.NetworkServerControlImpl.init (Неизвестный источник)
в org.apache.derby.impl.drda.NetworkServerControlImpl. (неизвестный источник)
в org.apache.derby.drda.NetworkServerControl.main (неизвестный источник)
Я знаю, что эта строка находится в файле политики (и не закомментирована):
permission org.apache.derby.security.SystemPermission "engine", "usederbyinternals";
Однако я не думаю, что он даже забирает наш файл политики, так как если мы изменим нашу ссылку на несуществующий файл политики, мы все равно получим ту же ошибку.