Właściwość bazy danych (po ustawieniu na ON) zasadniczo deklaruje programowi SQL Server, że kod zawarty w tej bazie danych i wykonujący w podszytym kontekście, powinien mieć możliwość dotarcia poza tę bazę danych, przy jednoczesnym zachowaniu tego podszytego kontekstu bezpieczeństwa . Zezwala również na konfigurowanie zespołów SQLCLR w tej bazie danych na i UNSAFE, niezależnie od tego, czy ten kod sięga poza serwer (poza tym: dostęp do sieci, dostęp do systemu plików, dostęp do rejestru, dostęp do środowiska itp.).
Jest to raczej rodzajowy sposób na to, ponieważ obejmuje cały kod w bazie danych. Używanie certyfikatów i/lub kluczy asymetrycznych do podpisywania modułów - proc i/lub złożeń - pozwala na bardziej szczegółową kontrolę nad tym, jaki kod ma odpowiednie uprawnienia.
Ustawienie bazy danych na TRUSTWORTHY pozwala również na rozpoczęcie procesu w tej bazie danych na poziomie serwera i/lub na inne bazy danych. Zwykle proces jest zamknięty/poddany kwarantannie w bazie danych, w której został uruchomiony. Jeśli baza danych jest własnością logowania "sa", wówczas każdy proces zainicjowany w tej bazie danych i uruchomiony jako "dbo" będzie miał faktycznie uprawnienia "sa" (yikes!).
Zamiast próbować tutaj opisać, w wysokości szczegółowości wymaganym do pełni komunikować specyfiki o personifikacji, wydłużanie tego personifikacji, podpisywanie modułów itp, polecam uważne następujące zasoby na ten temat:
Należy unikać ustawiania bazy danych na TRUSTWORTHY tak bardzo, jak to możliwe. Jeśli naprawdę musisz mieć wielowątkowość/asynchroniczne wywołania I jeśli masz kod źródłowy i kompilujesz złożenie, to nie mogę wymyślić powodu, aby użyć opcji SET TRUSTWORTHY ON. Zamiast tego, należy podpisać zespół hasłem i użyć następujących poleceń ustawić preferowaną metodą pozwalając EXTERNAL_ACCESS i UNSAFE zespoły:
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];
Raz, że jest na swoim miejscu, można przejść do bazy danych, gdzie Twój zespół został załadowany i uruchom:
ALTER ASSEMBLY [MyAssembly] WITH PERMISSION_SET = UNSAFE;
Albo mogłeś zawarte WITH PERMISSION_SET = UNSAFE na końcu komendy CREATE ASSEMBLY.
Są one faktycznie podpisane za pomocą klucza asymetrycznego i ustawione na niebezpieczne, ale nadal otrzymują ten błąd. nie wiesz, dlaczego – cdub
+1 za oferowanie rozwiązania zastępczego, ale tak naprawdę nie rozwiązałeś prawdziwego pytania (konkretne i jednoznaczne ryzyko dotyczące TRUSTWORTHY w ogóle). –
@chris Czy na pewno zestaw jest ustawiony na UNSAFE? Wystąpił błąd, który pojawia się, gdy zestaw nie jest ustawiony jako niebezpieczny. Lub, gdy został ustawiony na UNSAFE, ale potem Login został usunięty lub przynajmniej usunięto uprawnienie "UNSAFE ASSEMBLY". Jeśli tak nie jest, to jakie metody ramowe wywołujesz w swojej procedurze proc? –