TRUSTWORTHY свойства базы данных (если установлено в ON) по существу декларирует к SQL Server, что код, содержащийся в этой базе данных, и исполняющий в олицетворенном контексте, должен быть позволено достичь за пределами этой базы данных, сохраняя при этом, что изображал контекст безопасности , Он также допускает все SQLCLR Агрегаты в этой базе данных должны быть установлены в EXTERNAL_ACCESS и UNSAFE, независимо от того, распространяется ли этот код за пределы сервера (вне контекста: доступ к сети, доступ к файловой системе, доступ к реестру, доступ к среде и т. Д.).
Это довольно общее средство для этого, поскольку оно охватывает весь код в базе данных. Использование сертификатов и/или асимметричных ключей для подписи модулей - procs и/или сборок - позволяет более детально контролировать, какой код имеет какие разрешения.
Установка базы данных на TRUSTWORTHY также позволяет любому процессу, начиная с этой базы данных, доходить до уровня сервера и/или переходить в другие базы данных. Обычно процесс ограничивается/помещается на карантин в базу данных, где он был запущен. Если база данных принадлежит «sa» Login, то любой процесс, инициированный в этой базе данных и работающий как «dbo», будет иметь «sa» привилегии (yikes!).
Вместо того, чтобы пытаться описать здесь, в количестве деталей, необходимое для полного общения особенности о олицетворении, простираясь сказал олицетворение, подписывая модули и т.д., я рекомендую просматривал следующие ресурсы по этой теме:
Вам следует избегать установки базы данных на TRUSTWORTHY в максимально возможной степени. Если у вас действительно есть многопоточные/асинхронные вызовы И если у вас есть исходный код и компилируете сборку, то я не могу придумать причину использования опции SET TRUSTWORTHY ON. Вместо этого, вы должны подписать сборку с паролем и использовать следующие команды, чтобы установить предпочтительный способ позволять EXTERNAL_ACCESS и UNSAFE сборки:
USE [master];
CREATE ASYMMETRIC KEY [ClrPermissionsKey]
AUTHORIZATION [dbo]
FROM EXECUTABLE FILE = 'C:\path\to\my\assembly.dll';
CREATE LOGIN [ClrPermissionsLogin]
FROM ASYMMETRIC KEY [ClrPermissionsKey];
GRANT UNSAFE ASSEMBLY TO [ClrPermissionsLogin];
После того, что находится в месте, вы можете пойти в базу данных, где сборка была загружена и запуск:
ALTER ASSEMBLY [MyAssembly] WITH PERMISSION_SET = UNSAFE;
Или вы могли бы включили WITH PERMISSION_SET = UNSAFE в конце команды CREATE ASSEMBLY.
Они фактически подписаны с асимметричным ключом и установлены на небезопасные, но все же получают эту ошибку. не знаю, почему – cdub
+1 для предложения допустимого обходного пути, но вы действительно не рассматривали реальный вопрос (конкретные и явные риски в отношении TRUSTWORTHY в целом). –
@chris Вы уверены, что сборка настроена на UNSAFE? Ошибка, которую вы опубликовали, - это то, что вы получаете, когда сборка не настроена на небезопасную. Или, когда он был установлен в UNSAFE, но затем был удален или был удален, или, по крайней мере, было удалено разрешение «UNSAFE ASSEMBLY». Если это не так, то какие методы структуры вы вызываете в своем методе proc? –