Spec-Zone .ru
спецификации, руководства, описания, API
|
Политика для среды приложения языка программирования Java™ (определение, какие полномочия доступны для кода из различных источников, и выполняющийся как различные принципалы) представляется объектом Политики. Более определенно это представляется a Policy
подкласс, обеспечивающий реализацию абстрактных методов в Policy
class (который находится в java.security
пакет).
Исходное расположение для информации о политике, используемой объектом Политики, до реализации Политики. Ссылочная реализация Политики получает свою информацию из статических конфигурационных файлов политики.
Остальная часть этого документа принадлежит ссылочной реализации Политики и синтаксису, который должен использоваться в файлах политики, которые это читает. Для получения информации об использовании Средства осуществления политики, чтобы создать файл политики (не будучи должен знать необходимый синтаксис), см. документацию Средства осуществления политики (для Соляриса/Linux) (для Windows).
Вот схема для остальной части этого документа:
Файл политики может быть составлен через простой текстовый редактор, или через графическую утилиту 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=mypolicy SomeApp
-Djava.security.manager
"параметр гарантирует, что менеджер безопасности значения по умолчанию устанавливается, и таким образом приложение подвергается проверкам политики. Это не требуется если приложение SomeApp
устанавливает менеджера безопасности.Если Вы используете
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
"свойство в файле свойств безопасности устанавливается в ложь. Значение по умолчанию является истиной. Альтернативная политика, которую class может быть дан, чтобы заменить ссылочную реализацию Политики class, пока прежний - подкласс абстрактной Политики class и реализует getPermissions
метод (и другие методы по мере необходимости).
Ссылочная реализация Политики может быть изменена, редактируя файл свойств безопасности, который является java.security
файл в lib/security
каталог JDK или JRE.
Один из типов свойств можно начаться java.security
имеет следующую форму:
policy.provider=PolicyClassName
PolicyClassName
должен определить полностью определенное имя требуемого Policy
реализация class. Запись файла свойств безопасности значения по умолчанию для этого свойства является следующим:
policy.provider=sun.security.provider.PolicyFile
Чтобы настроить, можно изменить значение свойства, чтобы определить другой class, как в
policy.provider=com.mycom.MyPolicy
Конфигурационный файл (ы) политики для JDK или установки JRE определяет то, что полномочия (который типы доступов системного ресурса) предоставляют кодировать из указанного источника кода, и выполняемый как указанный принципал.
Для апплета (или приложение, работающее под менеджером безопасности), чтобы быть позволенным выполнить защищенные действия (такие как чтение или запись файла), апплету (или приложение) нужно предоставить разрешение для того определенного действия. В ссылочной реализации Политики то разрешение должна предоставить запись предоставления в конфигурационном файле политики. См. ниже и "Спецификация Архитектуры безопасности Java" для получения дополнительной информации. (Единственное исключение - то, что у кода всегда автоматически есть разрешение, чтобы считать файлы из его того же самого (URL) расположение, и подкаталоги того расположения; это не нуждается в явном разрешении, чтобы сделать так.)
Конфигурационный файл политики по существу содержит список записей. Это может содержать "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/.keystoreURL может также быть абсолютным.
Тип 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
значение может быть списком разделенных запятой значений многократных псевдонимов. Примером является "Адам, Канун, Чарльз", что означает "подписанный Адамом и Евой и Чарльзом"; отношение И, не ИЛИ. Чтобы быть более точным, оператор как "Код, подписанный Адамом", означает "Код в файле class, содержавшемся в JAR, который подписывается, используя закрытый ключ, соответствующий сертификату с открытым ключом в keystore, запись которого искажается Адамом".
signedBy
поле является дополнительным в этом, если оно опускается, оно показывает "любое подписывающее лицо". Не имеет значения, подписывается ли код или не или кого.
Основное значение определяет a class_name
/principal_name
пара, которая должна присутствовать в пределах основного набора выполняющегося потока. Основной набор связывается с выполняющимся кодом посредством Предмета.
principal_class_name
может быть установлен в подстановочное значение, *, который позволяет ему соответствовать любому Principal
class. Кроме того, principal_name
май также быть установленным в подстановочное значение, *, позволяя это соответствовать любому Principal
имя. Устанавливая principal_class_name
или principal_name
к *, не окружайте * кавычками. Кроме того, если Вы определяете подстановочный принципал class, следует также определить подстановочное имя принципала.
Основное поле является дополнительным в этом, если оно опускается, оно показывает "любые принципалы".
Примечание по Замене Псевдонима 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
с запаздыванием "/" соответствует все файлы class (не файлы JAR) в указанном каталоге. A codeBase
с запаздыванием "/*" соответствует все файлы (и class и файлы JAR) содержавшийся в том каталоге. A codeBase
с запаздыванием "/-" соответствует все файлы (и class и файлы 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
пара имя/значение для записи разрешения является дополнительной. Если существующий, это указывает на подписанное разрешение. Таким образом, само разрешение class должно быть подписано данным псевдонимом (ами) для разрешения, которое будет предоставлено. Например, предположите, что у Вас есть следующая запись предоставления:
grant { permission Foo "foobar", signedBy "FooSoft"; };
Затем это разрешение типа Foo предоставляют если Foo.class
разрешение было помещено в файл JAR, и файл JAR был подписан закрытым ключом, соответствующим открытому ключу в сертификате, определенном псевдонимом "FooSoft", или если Foo.class
система class, так как системные классы не подвергаются ограничениям политики.
Элементы, которые появляются в записи разрешения, должны появиться в указанном порядке (permission
, permission_class_name, "target_name", "действие", и signedBy
"signer_names"). Запись завершается с точкой с запятой.
Случай незначителен для идентификаторов (permission
, signedBy
, codeBase
, и т.д.), но является существенным для permission_class_name или для любой строки, в которой передают как значение.
Отметьте: Когда Вы определяете 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.*"; };Это определяет, что только кодируют, который удовлетворяет, следующие условия могут вызвать методы в Безопасности class, чтобы добавить или удалить провайдеров или установить свойства Security:
/home/sysadmin/
"каталог на локальной файловой системе.Или компонент источника кода (или оба) могут отсутствовать. Пример, где 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 запись игнорируется.
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}}
Есть два протокола, поддерживаемые в реализации файла политики значения по умолчанию:
${{self}}
Протокол, self
, обозначает замену всей строки, ${{self}}
, с одним или более основными class / называют пар. Точная выполняемая замена зависит от содержания пункта предоставления, которому принадлежит разрешение.
Если пункт предоставления не будет содержать основной информации, то разрешение будет проигнорировано (полномочия, содержащие ${{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}}
будет заменен тем же самым списком разделенных запятой значений или принципалами. В случае, где оба основной class и имя являются 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"
.${{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"
. Запись разрешения игнорируется под следующими состояниями ошибки:
alias_name
не обеспечиваетсяalias_name
не может быть получен