Ватсон Карли
Шрифт:
Политика безопасности определяет, какие действия разрешается выполнять сборками в группе кода. Давайте обсудим полномочия доступа к коду, предоставляемые CLR. Нижеследующий список показывает, какие возможности предоставляют полномочия доступа к коду:
□ DirectoryServicesPermission — получение доступа к активному каталогу (Active Directory) с помощью классов
□ DnsPermission — использование системы имен доменов TCP/IP (DNS).
□ EnvironmentPermission — чтение и запись переменных окружения.
□ EventLogPermission — чтение и запись в журнал событий.
□ FileDialogPermission — доступ к файлам, которые были выбраны пользователем в диалоговом окне Open.
□ FileIOPermission — работа с файлами (чтение, запись и добавление в файл, а также создание и изменение папок).
□ IsolatedStorageFilePermission — доступ к закрытым виртуальным файловым системам.
□ IsolatedStoragePermission — доступ к изолированной памяти; памяти, которая ассоциируется с отдельным пользователем и с некоторыми аспектами идентичности кода, такими как его web-сайт, сигнатура или издатель.
□ MessageQueuePermission — использование очереди сообщений с помощью Microsoft Message Queue.
□ OleDbPermission — доступ к базам данных с помощью OLE DB.
□ PerformanceCounterPermission — использование показателей производительности.
□ PrintingPermission — доступ к печати.
□ ReflectionPermission — доступ к информации о типе с помощью
□ RegistryPermission — чтение, запись, создание или удаление ключей и значений в реестре.
□ SecurityPermission — выполнение, объявление полномочий, обращение к неуправляемому коду, пропуск проверки, и другие полномочия.
□ ServiceControllerPermission — получение доступа (для выполнения или остановки) к службам Windows.
□ SocketPermission — создание или принятие соединения TCP/IP на транспортном адресе.
□ SQLClientPermission — доступ к базам данных SQL.
□ UIPermission — доступ к интерфейсу пользователя.
□ WebPermission — осуществление или принятие соединения с/из Web.
С помощью любого из этих классов полномочий определяется еще более глубокий уровень детализации. Позже будет показан пример, запрашивающий не просто доступ к файлу, а определенный уровень такого доступа.
С практической точки зрения настоятельно рекомендуется все попытки использования ресурсов, связанных с полномочиями в этом списке, помещать внутри блоков обработки ошибок try-catch, чтобы приложение ухудшалось постепенно, если ему придется выполняться с ограниченными полномочиями. Конструкция приложения должна определять, как приложение будет действовать в такой ситуации, не стоит предполагать, что оно начнет выполняться с такой же политикой системы безопасности, с которой оно разрабатывалось. Например, если приложение не может обратиться к локальному диску, закончится ли оно или должно действовать другим способом?
Сборка связывается с несколькими группами кода, действующие полномочия сборки в рамках политики системы безопасности являются объединением всех полномочий, предоставленных всем группам кода, которым эта сборка принадлежит. В результате, каждая группа кода, которой соответствует сборка, будет расширять набор допустимых действий сборки. Отметим, что группы кода, расположенные ниже в дереве, часто присваивают более свободные полномочия, чем расположенные выше.
Существует другое множество полномочий, которыми располагает CLR на основе идентичности кода. Эти права не могут быть предоставлены явно, так как они связаны непосредственно со свидетельством, которое CLR сопоставляет со сборкой, и называются полномочиями идентичности (Identity Permisssions). Вот имена классов для полномочий идентичности:
□ PublisherIdentityPermission — цифровая подпись издателя программного обеспечения.
□ SiteIdentityPermission — расположение web-сайта, из которого получен код.
□ StrongNameIdentityPermission — устойчивое имя сборки.
□ URLIdentityPermission — URL, откуда получен код (включая протокол, например
□ ZoneIdentityPermission — зона, являющаяся местом происхождения сборки.