Представляет интерес вопрос, как действует

, когда машина имеет несколько установок .NET. При таких обстоятельствах выполняемая копия будет изменять политику безопасности только для связанной с ней установкой .NET. Чтобы сохранить простым управление политикой безопасности, вполне можно удалить предыдущие копии .NET при установке последующих версий.

Сборки соответствуют группам кода в зависимости от условий членства. Если вернуться к примеру групп кода и загрузить сборку с web-сайтаона будет соответствовать группам кода таким образом:

Сборка является членом корневой группы кода (All Code); так как она приходит из локальной сети, то она является также членом группы кода Intranet, но вследствие того, что она была загружена со специального сайтато ей также предоставляется

, что соответствует выполнению без ограничений.

Легко увидеть группы кода, членом которых является сборка, используя команду:

Выполнение этой команды для сборки на локальном диске создает вывод:

Можно заметить, что группы кода перечислены на трех уровнях — Enterprise, Machine и User (Предприятие, Машина и Пользователь). В данный момент сосредоточимся только на уровне Machine, два других более подробно рассмотрим позже. Если вы желаете знать об отношениях между тремя уровнями, то эффективные полномочия, предоставляемые сборке, являются пересечением полномочий из трех уровней. Например, если удалить полномочие

из зоны Internet политики на уровне Enterprise, то все полномочия отменяются для кода из зоны Internet и настройки двух других уровней становятся неподходящими.

Теперь используем эту команду для той же сборки, но через HTTP на удаленном сервере. Мы увидим, что сборка является членом различных групп, которые имеют более ограничительные права:

Для сборки в этот раз можно видеть, что пересечение полномочий оставляет полномочия

и ocket.

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

После того как сборка сопоставлена с группами кода, CLR просматривает политику системы безопасности для определения предоставляемых сборке полномочий. Это на самом деле похоже на систему безопасности учетных записей пользователей в Windows 2000. Полномочия обычно применяются не к пользователям, а к группам. То же самое справедливо для сборок: полномочия применяются к группам кода, а не к отдельным сборкам, что делает управление политикой системы безопасности в .NET гораздо более простой задачей.