Spec-Zone .ru
спецификации, руководства, описания, API
Содержание документации

Синтаксис Файла Реализации и Политики Политики по умолчанию

Политика для среды приложения языка программирования Java™ (определение, какие полномочия доступны для кода из различных источников, и выполняющийся как различные принципалы) представляется объектом Политики. Более определенно это представляется a Policy подкласс, обеспечивающий реализацию абстрактных методов в Policy класс (который находится в java.security пакет).

Исходное расположение для информации о политике, используемой объектом Политики, до реализации Политики. Ссылочная реализация Политики получает свою информацию из статических конфигурационных файлов политики.

Остальная часть этого документа принадлежит ссылочной реализации Политики и синтаксису, который должен использоваться в файлах политики, которые это читает. Для получения информации об использовании Средства осуществления политики, чтобы создать файл политики (не будучи должен знать необходимый синтаксис), см. документацию Средства осуществления политики (для Соляриса/Linux) (для Windows).

Вот схема для остальной части этого документа:

Реализация Политики по умолчанию
Расположение файлов Политики по умолчанию
Изменение Реализации Политики
Синтаксис Файла политики
Примеры Файла политики
Расширение свойства в Файлах Политики
Общее Расширение в Файлах Политики
Связанная Документация

Реализация Политики по умолчанию

В ссылочной реализации Политики политика может быть определена в пределах одного или более конфигурационных файлов политики. Конфигурационный файл (ы) определяет то, что полномочия позволяются для кода из указанного источника кода, и выполняются указанным принципалом. Каждый конфигурационный файл должен быть закодирован в UTF-8.

Файл политики может быть составлен через простой текстовый редактор, или через графическую утилиту Policy Tool.

Есть по умолчанию единственный файл политики в масштабе всей системы, и единственный (дополнительный) пользовательский файл политики.

Ссылочная реализация Политики инициализируется в первый раз getPermissions метод вызывают, или всякий раз, когда refresh метод вызывают. Инициализация включает парсинг конфигурационного файла (ов) политики (см. Синтаксис Файла Политики), и затем заполнение объекта Политики.

Расположение файлов Политики по умолчанию

Как упомянуто ранее, есть по умолчанию единственный файл политики в масштабе всей системы, и единственный пользовательский файл политики.

Системный файл политики по умолчанию располагается в

java.home/lib/security/java.policy  (Solaris/Linux)
java.home\lib\security\java.policy  (Windows)

Отметьте: java.home обращается к значению системного свойства, названного"java.home", который определяет каталог, который содержит среду выполнения - или каталог jre в Java Комплект разработчика SE (JDK) или высокоуровневый каталог Java Среда выполнения SE (JRE).

Системный файл политики предназначается, чтобы предоставить полномочия кода в масштабе всей системы. java.policy файл, установленный с JDK, предоставляет все полномочия стандартным расширениям, позволяет любому слушать на непривилегированных портах, и позволяет любому коду читать определенные "стандартные" свойства, которые не чувствительны к безопасности, такой как"os.name"и"file.separator"свойства.

Пользовательский файл политики по умолчанию располагается в

user.home/.java.policy  (Solaris/Linux)
user.home\.java.policy  (Windows)

Отметьте: user.home обращается к значению системного свойства, названного"user.home", который определяет корневой каталог пользователя.

Когда Политика инициализируется, системная политика загружается в первом, и затем пользовательская политика добавляется к этому. Если никакая политика не присутствует, встроенная политика используется. Эта встроенная политика является тем же самым как java.policy файлом, установленным с JRE.

Расположение файлов политики определяется в файле свойств безопасности, который располагается в

java.home/lib/security/java.security  (Solaris/Linux)
java.home\lib\security\java.security  (Windows)
Как отмечено выше, java.home указывает на каталог, который содержит среду выполнения - или каталог jre в JDK или высокоуровневый каталог JRE. Расположение файлов политики определяется как значения свойств, имена которых имеют форму
policy.url.n
где n число. Вы определяете каждое такое значение свойства в строке следующей формы:
policy.url.n=URL
Здесь, URL спецификация URL.

Например, система по умолчанию и пользовательские файлы политики определяются в файле свойств безопасности как

policy.url.1=file:${java.home}/lib/security/java.policy
policy.url.2=file:${user.home}/.java.policy

(См. Расширение Свойства для информации об определении значений свойств через специальный синтаксис, таких как определение java.home значение свойства через ${java.home}.)

Можно фактически определить много URL (включая формы"http://"), и все определяемые файлы политики будет загружен. Можно также прокомментировать или изменить второй, чтобы отключить чтение пользовательского файла политики по умолчанию.

Алгоритм запускается в policy.url.1, и продолжает постепенно увеличиваться, пока это не находит URL. Таким образом, если Вы имеете policy.url.1 и policy.url.3, policy.url.3 никогда не будет читаться.

Определение Дополнительного Файла Политики во Время выполнения

Также возможно определить дополнительное или различный файл политики, вызывая выполнение приложения. Это может быть сделано через"-Djava.security.policy"параметр командной строки, который устанавливает значение java.security.policy свойство. Например, если Вы используете

    java -Djava.security.manager -Djava.security.policy=someURL SomeApp
где someURL URL, определяющий расположение файла политики, тогда указанный файл политики будет загружен в дополнение ко всем файлам политики, которые определяются в файле свойств безопасности.

Примечания:

Если Вы используете

    java -Djava.security.manager -Djava.security.policy==someURL SomeApp
(отметьте, что двойное равняется), тогда только, указанный файл политики будет использоваться; все те обозначенные в файле свойств безопасности будут проигнорированы.

Если Вы хотите передать файл политики к appletviewer, то используйте"-J-Djava.security.policy"параметр следующим образом:

    appletviewer -J-Djava.security.policy=someURL myApplet
Отметьте:"-Djava.security.policy"значение файла политики будет проигнорировано (для обоих java и appletviewer команды), если"policy.allowSystemProperty"свойство в файле свойств безопасности устанавливается в ложь. Значение по умолчанию является истиной.

Изменение Реализации Политики

Альтернативный класс политики может быть дан, чтобы заменить ссылочный класс реализации Политики, пока прежний - подкласс абстрактного класса Политики и реализует getPermissions метод (и другие методы по мере необходимости).

Ссылочная реализация Политики может быть изменена, редактируя файл свойств безопасности, который является java.security файл в lib/security каталог JDK или JRE.

Один из типов свойств можно начаться java.security имеет следующую форму:

    policy.provider=PolicyClassName

PolicyClassName должен определить полностью определенное имя требуемого Policy класс реализации. Запись файла свойств безопасности по умолчанию для этого свойства является следующим:

    policy.provider=sun.security.provider.PolicyFile

Чтобы настроить, можно изменить значение свойства, чтобы определить другой класс, как в

    policy.provider=com.mycom.MyPolicy

Синтаксис Файла политики

Конфигурационный файл (ы) политики для JDK или установки JRE определяет то, что полномочия (который типы доступов системного ресурса) предоставляют кодировать из указанного источника кода, и выполняемый как указанный принципал.

Для апплета (или приложение, работающее под менеджером безопасности), чтобы быть позволенным выполнить защищенные действия (такие как чтение или запись файла), апплету (или приложение) нужно предоставить разрешение для того определенного действия. В ссылочной реализации Политики то разрешение должна предоставить запись предоставления в конфигурационном файле политики. См. ниже и "Спецификация Архитектуры безопасности Java" для получения дополнительной информации. (Единственное исключение - то, что у кода всегда автоматически есть разрешение, чтобы считать файлы из его того же самого (URL) расположение, и подкаталоги того расположения; это не нуждается в явном разрешении, чтобы сделать так.)

Конфигурационный файл политики по существу содержит список записей. Это может содержать "keystore" запись, и содержит нуль или больше записей "предоставления".

Запись Keystore

keystore является базой данных закрытых ключей и их связанных цифровых сертификатов, таких как цепочки сертификата X.509, аутентифицирующие соответствующие открытые ключи. keytool утилита (для Соляриса/Linux) (для Windows) используется, чтобы создать и администрировать keystores. keystore, определенный в конфигурационном файле политики, используется, чтобы искать открытые ключи подписывающих лиц, определенных в записях предоставления файла. keystore запись должна появиться в конфигурационном файле политики, если какие-либо записи предоставления определяют псевдонимы подписывающего лица, или если какие-либо записи предоставления определяют основные псевдонимы (см. ниже).

В это время может быть только один keystore/keystorePasswordURL запись в файле политики (другие записи после первого игнорируются). Эта запись может появиться где угодно вне записей предоставления файла. У этого есть следующий синтаксис:

keystore "some_keystore_url", "keystore_type", "keystore_provider";
keystorePasswordURL "some_password_url";
some_keystore_url определяет расположение URL keystore, some_password_url определяет расположение URL keystore пароля, keystore_type определяет тип keystore, и keystore_provider определяет keystore провайдера. Отметьте что входной поток в some_keystore_url передается к KeyStore.load метод. Если NONE определяется как URL, затем нулевой поток передают к KeyStore.load метод. NONE должен быть определен если KeyStore не основано на файле, например, если это находится на аппаратном маркерном устройстве.

URL относительно расположения файла политики. Таким образом, если файл политики определяется в файле свойств безопасности как:

    policy.url.1=http://foo.example.com/fum/some.policy
и у того файла политики есть запись:
    keystore ".keystore";
тогда keystore будет загружен из:
    http://foo.example.com/fum/.keystore
URL может также быть абсолютным.

Тип keystore определяет хранение и формат данных keystore информации, и алгоритмы, используемые, чтобы защитить закрытые ключи в keystore и целостности keystore непосредственно. Тип по умолчанию, поддерживаемый Sun Microsystems, является собственным типом keystore под названием "JKS". Таким образом, если тип keystore является "JKS", он не должен быть определен в keystore записи.

Записи предоставления

Выполняемый код, как всегда полагают, прибывает из определенного "источника кода" (представленный объектом типа CodeSource). Источник кода включает не только расположение (URL) где код, порожденный из, но также и ссылка на сертификат (ы), содержащий открытый ключ (и), соответствующий закрытому ключу (ам), используемому, чтобы подписать код. На сертификаты в источнике кода ссылаются символьные имена псевдонима от keystore пользователя. Код, как также полагают, выполняется как определенный принципал (представленный объектом типа Principal), или группа принципалов.

Каждая запись предоставления включает одну или более "записей разрешения, которым" предшествуют дополнительным codeBase, signedBy, и основные пары имя/значение, которые определяют, какой код Вы хотите предоставить полномочиям. Основной формат записи предоставления является следующим:

  grant signedBy "signer_names", codeBase "URL",
        principal principal_class_name "principal_name",
        principal principal_class_name "principal_name",
        ... {

      permission permission_class_name "target_name", "action", 
          signedBy "signer_names";
      permission permission_class_name "target_name", "action", 
          signedBy "signer_names";
      ...
  };
        
Все некурсивные элементы выше должны появиться, как (хотя случай не имеет значения, и некоторые являются дополнительными, как отмечено ниже). Курсивные элементы представляют значения переменных.

Запись предоставления должна начаться со слова grant.

SignedBy, Principal, и CodeBase Поля

signedBy, codeBase, и principal значения являются дополнительными, и порядок этих полей не имеет значения.

A signedBy значение указывает на псевдоним для сертификата, сохраненного в keystore. Открытый ключ в пределах того сертификата используется, чтобы проверить цифровую подпись на коде; Вы предоставляете, что разрешение (я) кодирует подписанный закрытым ключом, соответствующим открытому ключу в keystore записи, определенной псевдонимом.

signedBy значение может быть списком разделенных запятой значений многократных псевдонимов. Примером является "Адам, Канун, Чарльз", что означает "подписанный Адамом и Евой и Чарльзом"; отношение И, не ИЛИ. Чтобы быть более точным, оператор как "Код, подписанный Адамом", означает "Код в файле класса, содержавшемся в JAR, который подписывается, используя закрытый ключ, соответствующий сертификату с открытым ключом в keystore, запись которого искажается Адамом".

signedBy поле является дополнительным в этом, если оно опускается, оно показывает "любое подписывающее лицо". Не имеет значения, подписывается ли код или не или кого.

Основное значение определяет a class_name/principal_name пара, которая должна присутствовать в пределах основного набора выполняющегося потока. Основной набор связывается с выполняющимся кодом посредством Предмета.

principal_class_name может быть установлен в подстановочное значение, *, который позволяет ему соответствовать любому Principal класс. Кроме того, principal_name май также быть установленным в подстановочное значение, *, позволяя это соответствовать любому Principal имя. Устанавливая principal_class_name или principal_name к *, не окружайте * кавычками. Кроме того, если Вы определяете подстановочный класс принципала, следует также определить подстановочное имя принципала.

Основное поле является дополнительным в этом, если оно опускается, оно показывает "любые принципалы".

Примечание по Замене Псевдонима KeyStore:

Если принципал class_name/principal_name пара определяется как единственная заключенная в кавычки строка, это обрабатывается как псевдоним keystore. С keystore консультируются и запрашивается (через псевдоним) для Сертификата X509. Если Вы находитесь, принципал class_name автоматически обрабатывается как javax.security.auth.x500.X500Principal, и principal_name автоматически обрабатывается как подчиненное отличительное имя от сертификата. Если отображение Сертификата X509 не находится, вся запись предоставления игнорируется.

A codeBase значение указывает на исходное расположение кода; Вы предоставляете, что разрешение (я) кодирует от того расположения. Пустое codeBase запись показывает "любой код"; не имеет значения, где код происходит из.

Отметьте: a codeBase значение является URL и таким образом не должно всегда использовать наклонные черты (никогда наклонные черты влево) как разделитель каталога, даже когда источник кода находится фактически на системе Windows. Таким образом, если исходное расположение для кода системы Windows фактически C:\somepath\api\, тогда политика codeBase запись должна быть похожей:

    grant codeBase "file:/C:/somepath/api/" {
        ...
    };
Точное значение a codeBase значение зависит от символов в конце. A codeBase с запаздыванием "/" соответствует все файлы класса (не файлы JAR) в указанном каталоге. A codeBase с запаздыванием "/*" соответствует все файлы (и класс и файлы JAR) содержавшийся в том каталоге. A codeBase с запаздыванием "/-" соответствует все файлы (и класс и файлы JAR) в каталоге и рекурсивно всех файлах в подкаталогах, содержавшихся в том каталоге. Следующая таблица иллюстрирует различные случаи.
Кодовая база URL Загруженного Кода Кодовая база URL в Политике Соответствие?
java.sun.com/people/gong/ java.sun.com/people/gong Y
java.sun.com/people/gong/ java.sun.com/people/gong/ Y
java.sun.com/people/gong/ java.sun.com/people/gong/* Y
java.sun.com/people/gong/ java.sun.com/people/gong/ - Y
java.sun.com/people/gong/appl.jar java.sun.com/people/gong/ N
java.sun.com/people/gong/appl.jar java.sun.com/people/gong/ - Y
java.sun.com/people/gong/appl.jar java.sun.com/people/gong/* Y
java.sun.com/people/gong/appl.jar java.sun.com/people/ - Y
java.sun.com/people/gong/appl.jar java.sun.com/people/* N
java.sun.com/people/gong/ java.sun.com/people/ - Y
java.sun.com/people/gong/ java.sun.com/people/* N

Записи Разрешения

Запись разрешения должна начаться со слова permission. Слово permission_class_name в шаблоне выше фактически был бы определенный тип полномочий, такой как java.io.FilePermission или java.lang.RuntimePermission.

"action"требуется для многих типов полномочий, такой как java.io.FilePermission (где это определяет, какой доступ к файлу разрешается). Это не требуется для категорий такой как java.lang.RuntimePermission где это не необходимо - Вы любому определили разрешение"target_name"значение после permission_class_name или Вы не делаете.

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

  grant {
      permission Foo "foobar", signedBy "FooSoft";
  };

Затем это разрешение типа Foo предоставляют если Foo.class разрешение было помещено в файл JAR, и файл JAR был подписан закрытым ключом, соответствующим открытому ключу в сертификате, определенном псевдонимом "FooSoft", или если Foo.class системный класс, так как системные классы не подвергаются ограничениям политики.

Элементы, которые появляются в записи разрешения, должны появиться в указанном порядке (permission, permission_class_name, "target_name", "действие", и signedBy "signer_names"). Запись завершается с точкой с запятой.

Случай незначителен для идентификаторов (permission, signedBy, codeBase, и т.д.), но является существенным для permission_class_name или для любой строки, в которой передают как значение.

Отметьте Относительно Спецификаций Пути к файлу на Windows Systems

Отметьте: Когда Вы определяете a java.io.FilePermission,"target_name"путь к файлу. На системах Windows, всякий раз, когда Вы непосредственно определяете путь к файлу в строке (но не в кодовой базе URL), Вы должны включать две наклонных черты влево для каждой фактической единственной наклонной черты влево в пути, как в

  grant {
      permission java.io.FilePermission "C:\\users\\cathy\\foo.bat", "read";
  };
Причина это необходимо, состоит в том, потому что строки обрабатываются токенизатором (java.io.StreamTokenizer), который позволяет"\"чтобы использоваться в качестве строки escape (например,"\n"чтобы указать на новую строку) и который таким образом требует, чтобы две наклонных черты влево указали на единственную наклонную черту влево. После того, как токенизатор обработал вышеупомянутую строку пути к файлу, преобразовывая двойные наклонные черты влево в единственные наклонные черты влево, конечный результат
    "C:\users\cathy\foo.bat"

Примеры Файла политики

Пример двух записей в конфигурационном файле политики

  // If the code is signed by "Duke", grant it read/write access to all 
  // files in /tmp:
  grant signedBy "Duke" {
      permission java.io.FilePermission "/tmp/*", "read,write";
  };

  // Grant everyone the following permission:
  grant { 
      permission java.util.PropertyPermission "java.vendor", "read";
  };
 

Содержание другого демонстрационного конфигурационного файла политики появляется ниже.

  grant signedBy "sysadmin", codeBase "file:/home/sysadmin/*" {
      permission java.security.SecurityPermission "Security.insertProvider.*";
      permission java.security.SecurityPermission "Security.removeProvider.*";
      permission java.security.SecurityPermission "Security.setProperty.*";
  };
Это определяет, что только кодируют, который удовлетворяет, следующие условия могут вызвать методы в классе Безопасности, чтобы добавить или удалить провайдеров или установить свойства Security:

Или компонент источника кода (или оба) могут отсутствовать. Пример, где codeBase отсутствует:

  grant signedBy "sysadmin" {
      permission java.security.SecurityPermission "Security.insertProvider.*";
      permission java.security.SecurityPermission "Security.removeProvider.*";
  };
Если эта политика в действительности, кодируйте, который прибывает в Файл JAR, подписанный "sysadmin", могут добавить/удалить провайдеры, независимо от где Файл JAR, порожденный из.

Пример без подписывающего лица:

  grant codeBase "file:/home/sysadmin/-" {
      permission java.security.SecurityPermission "Security.insertProvider.*";
      permission java.security.SecurityPermission "Security.removeProvider.*";
  };
В этом случае, код, который прибывает отовсюду ниже"/home/sysadmin/"каталог на локальной файловой системе может добавить/удалить провайдеров. Код не должен быть подписан.

Пример, где ни один codeBase ни signedBy включается:

  grant {
      permission java.security.SecurityPermission "Security.insertProvider.*";
      permission java.security.SecurityPermission "Security.removeProvider.*";
  };
Здесь, с обоими исходными компонентными без вести пропавшими кода, любой код (независимо от того, где это произошло из, или подписывается ли это, или кто подписал это) может добавить/удалить провайдеров.

Следующее представляет основанную на принципале запись.

  grant principal javax.security.auth.x500.X500Principal "cn=Alice" {
      permission java.io.FilePermission "/home/Alice", "read, write";
  };
Это разрешает любой код, выполняющийся как X500Principal,"cn=Alice", разрешение, чтобы читать и записать в"/home/Alice".

Следующее представляет основанную на принципале запись с подстановочным значением.

  grant principal javax.security.auth.x500.X500Principal * {
      permission java.io.FilePermission "/tmp", "read, write";
  };
Это разрешает любому коду, выполняющемуся как X500Principal (независимо от отличительного имени), разрешение читать и писать в"/tmp".

Следующий пример показывает оператор предоставления и с codesource и с основной информацией.

  grant codebase "http://www.games.example.com",
        signedBy "Duke",
        principal javax.security.auth.x500.X500Principal "cn=Alice" {
      permission java.io.FilePermission "/tmp/games", "read, write";
  };
Это позволяет код, загруженный с"www.games.example.com", подписанный"Duke", и выполняемый"cn=Alice", разрешение, чтобы читать и вписать"/tmp/games"каталог.

Следующий пример показывает оператор предоставления с заменой псевдонима KeyStore:

  keystore "http://foo.example.com/blah/.keystore";

  grant principal "alice" {
      permission java.io.FilePermission "/tmp/games", "read, write";
  };
"alice"будет заменен
    javax.security.auth.x500.X500Principal "cn=Alice"
принятие сертификата X.509, связанного с псевдонимом keystore, alice, имеет подчиненное отличительное имя"cn=Alice". Это позволяет код, выполняемый X500Principal"cn=Alice"разрешение, чтобы читать и вписать"/tmp/games"каталог.

Расширение свойства в Файлах Политики

Расширение свойства возможно в файлах политики и в файле свойств безопасности.

Расширение свойства подобно расширяющимся переменным в оболочке. Таким образом, когда строка как

    ${some.property}
появляется в файле политики, или в файле свойств безопасности, это будет расширено до значения системного свойства. Например,
    permission java.io.FilePermission "${user.home}", "read";
расширится"${user.home}"чтобы использовать значение "user.home" системного свойства. Если значение того свойства"/home/cathy", тогда вышеупомянутое эквивалентно
    permission java.io.FilePermission "/home/cathy", "read";
Чтобы помочь в независимых от платформы файлах политики, можно также использовать специальную нотацию"${/}", который является ярлыком для"${file.separator}". Это позволяет вещи как
    permission java.io.FilePermission "${user.home}${/}*", "read";
Если значение"user.home"свойство /home/cathy, и Вы находитесь на Солярисе/Linux, вышеупомянутое преобразовывается в:
    permission java.io.FilePermission "/home/cathy/*", "read";
Если с другой стороны"user.home"значение C:\users\cathy и Вы находитесь на системе Windows, вышеупомянутое преобразовывается в:
    permission java.io.FilePermission "C:\users\cathy\*", "read";
Кроме того, как особый случай, если Вы разворачиваете свойство в кодовой базе, такой как
    grant codeBase "file:${java.home}/lib/ext/"
тогда любые file.separator символы будут автоматически преобразованы в /'s. Таким образом на системе Windows, вышеупомянутое преобразовать в
    grant codeBase "file:C:/jdk1.4/jre/lib/ext/"
даже если"java.home"устанавливается в C:\jdk1.4\jre. Таким образом Вы не должны использовать ${/} в строках кодовой базы (и Вы не были должны).

Расширение свойства имеет место где угодно, двойная заключенная в кавычки строка позволяется в файле политики. Это включает"signer_names", "URL", "target_name", и"action"поля.

Позволяется ли расширение свойства, управляется значением"policy.expandProperties"свойство в файле свойств безопасности. Если значение этого свойства является истиной (значение по умолчанию), расширение позволяется.

Отметьте: невозможно использовать вложенные свойства; они не будут работать. Например,

    "${user.${foo}}"
не работает, даже если"foo"свойство устанавливается в"home". Причиной является синтаксический анализатор свойства, не распознает вложенные свойства; это просто ищет первое"${", и затем продолжает смотреть, пока это не находит первое"}"и попытки интерпретировать результат (в этом случае,"${user.$foo}") как свойство, но сбои, если нет такого свойства.

Отметьте: Если свойство не может быть расширено в записи предоставления, записи разрешения, или keystore записи, та запись игнорируется. Например, если системное свойство"foo"не определяется, и Вы имеете:

    grant codeBase "${foo}" {
        permission ...;
        permission ...;
    };
тогда все полномочия в этой записи предоставления игнорируются. Если Вы имеете
    grant {
        permission Foo "${foo}";
        permission Bar "barTarget";
    };
тогда только"permission Foo..."запись игнорируется. И наконец, если Вы имеете
    keystore "${foo}";
тогда keystore запись игнорируется.

Системы Windows, Пути к файлам, и Расширение Свойства

Как отмечено выше, на системах Windows, когда Вы непосредственно определяете путь к файлу в строке (но не в кодовой базе URL), Вы должны включать две наклонных черты влево для каждой фактической единственной наклонной черты влево в пути, как в
    grant {
        permission java.io.FilePermission "C:\\users\\cathy\\foo.bat", "read";
    };
Это - то, потому что строки обрабатываются токенизатором (java.io.StreamTokenizer), который позволяет"\"чтобы использоваться в качестве строки escape (например,"\n"чтобы указать на новую строку) и который таким образом требует, чтобы две наклонных черты влево указали на единственную наклонную черту влево. После того, как токенизатор обработал вышеупомянутую строку пути к файлу, преобразовывая двойные наклонные черты влево в единственные наклонные черты влево, конечный результат
    "C:\users\cathy\foo.bat"
Расширение свойства в строке имеет место после того, как токенизатор обработал строку. Таким образом, если у Вас есть строка
    "${user.home}\\foo.bat"
тогда сначала токенизатор обрабатывает строку, преобразовывая двойные наклонные черты влево в единственную наклонную черту влево, и результат
    "${user.home}\foo.bat"
Затем ${user.home} свойство расширяется, и конечный результат
    "C:\users\cathy\foo.bat"
принятие"user.home"значение C:\users\cathy. Конечно, для независимости от платформы, было бы лучше, если бы строка была первоначально определена без каких-либо явных наклонных черт, то есть, используя ${/} свойство вместо этого, как в
    "${user.home}${/}foo.bat"

Общее Расширение в Файлах Политики

Обобщенные формы расширения также поддерживаются в файлах политики. Например, имена разрешения могут содержать строку формы:
${{protocol:protocol_data}}
Если такая строка происходит на имя разрешения, то значение в протоколе определяет точный тип расширения, которое должно произойти, и protocol_data используется, чтобы помочь выполнить расширение. protocol_data может быть пустым, когда вышеупомянутая строка должна просто принять форму:
${{protocol}}

Есть два протокола, поддерживаемые в реализации файла политики по умолчанию:

  1. ${{self}}

    Протокол, self, обозначает замену всей строки, ${{self}}, с одной или более основными парами класса/имени. Точная выполняемая замена зависит от содержания пункта предоставления, которому принадлежит разрешение.

    Если пункт предоставления не будет содержать основной информации, то разрешение будет проигнорировано (полномочия, содержащие ${{self}} на их целевые имена только допустимы в контексте основанного на принципале пункта предоставления). Например, BarPermission будет всегда игнорироваться в следующем пункте предоставления:

                grant codebase "www.example.com", signedby "duke" {
                    permission BarPermission "... ${{self}} ...";
                };
            
    
    Если пункт предоставления содержит основную информацию, ${{self}} будет заменен той же самой основной информацией. Например, ${{self}} в BarPermission будет заменен javax.security.auth.x500.X500Principal "cn=Duke" в следующем пункте предоставления:
    grant principal javax.security.auth.x500.X500Principal "cn=Duke" {
        permission BarPermission "... ${{self}} ...";
    };
    
    Если есть список разделенных запятой значений принципалов в пункте предоставления, то ${{self}} будет заменен тем же самым списком разделенных запятой значений или принципалами. В случае, где оба основной класс и имя являются wildcarded в пункте предоставления, ${{self}} заменяется всеми принципалами, связанными с Subject в токе AccessControlContext.

    Следующий пример описывает сценарий, включающий обоих self и KeyStore замена псевдонима вместе:

    keystore "http://foo.example.com/blah/.keystore";
    
    grant principal "duke" {
        permission BarPermission "... ${{self}} ...";
    };
    
    В вышеупомянутом примере,"duke"будет сначала расширен в javax.security.auth.x500.X500Principal "cn=Duke" принятие сертификата X.509, связанного с KeyStore псевдоним,"duke", имеет подчиненное отличительное имя"cn=Duke". Затем, ${{self}} будет заменен той же самой основной информацией, которая была только расширена в пункте предоставления: javax.security.auth.x500.X500Principal "cn=Duke".
  2. ${{alias:alias_name}}

    Протокол, alias, обозначает java.security. KeyStore искажают замену. KeyStore используемый тот, определенный в KeyStore запись. alias_name представляет псевдоним в KeyStore. ${{alias:alias_name}} заменяется javax.security.auth.x500.X500Principal "DN", где DN представляет подчиненное отличительное имя сертификата, принадлежащего alias_name. Например:

    keystore "http://foo.example.com/blah/.keystore";
    
    grant codebase "www.example.com" {
        permission BarPermission "... ${{alias:duke}} ...";
    };
    
    В вышеупомянутом примере сертификат X.509, связанный с псевдонимом, duke, получается от KeyStore, foo.example.com/blah/.keystore. Принятие сертификата герцога определяет"o=dukeOrg, cn=duke"как подчиненное отличительное имя, тогда ${{alias:duke}} заменяется javax.security.auth.x500.X500Principal "o=dukeOrg, cn=duke".

    Запись разрешения игнорируется под следующими состояниями ошибки:

Связанная Документация


Oracle и/или его филиалы Авторское право © 1993, 2011, Oracle и/или его филиалы. Все права защищены.
Свяжитесь с Нами