Разве плохо использовать WITH PERMISSION_SET = UNSAFE для сборки в SQL 2005?

Question

Мне нужно использовать SQLCLR для создания хранимой процедуры, которая использует материал в .NET 3.5.Если я не использую PERMISSION_SET = UNSAFE, я не могу этого сделать, он просто умрет и выдаст мне эту ошибку:

Ошибка развертывания SQL01268: .Net SqlClient
Поставщик данных: Msg 6503, Уровень 16, Состояние 12, Строка 1
Сборка 'system.core, версия = 3.5.0.0, культура = нейтральная, publickeytoken = b77a5c561934e089.'не найден в каталоге SQL.
Произошла ошибка во время выполнения пакета.

Итак, я нашел эту статью:

http://weblogs.asp.net/paulomorgado/archive/2009/06/13/playing-with-sql-server-clr-integration-part-iv-deploying-to-sql-server-2005.aspx

И последняя строка гласит:

«Теперь администраторы баз данных определенно не позволят мне использовать это, но было интересно создать его».

Яне уверен, имел ли он в виду разрешение, установленное как «небезопасное».

Итак, может ли произойти какая-то огромная зияющая дыра, если вы сделаете это?

Answer 1

Существует три различных параметра allow_set, которые ограничивают возможности сборки

SAFE - ограничивает сборку управляемым кодом

EXTERNAL_ACCESS - разрешает доступ к файлам, сетевым ресурсам и т. Д.

UNSAFE - неограниченный доступ, включая выполнение неуправляемого кода

MSDN документы дают следующее руководство

Указание UNSAFE дает коду в сборке полную свободу для выполнения операций в пространстве процессов SQL Server, которые потенциально могут поставить под угрозу надежность SQL Server. UNSAFE-сборки также могут потенциально подорвать систему безопасности SQL Server или общеязыковой среды выполнения. UNSAFE-разрешения должны предоставляться только для сборок с высоким уровнем доверия.

Если ваша сборка использует только функции .NET 3.5, я не понимаю, зачем ей нужен UNSAFE доступ.

Возможно, вы используете один из типов или членов, запрещенных в библиотеке System.Core. У Microsoft есть список этих. Запрещенные типы и члены в System.Core.dll

Здесь есть дополнительная информация. Атрибуты защиты хоста и программирование интеграции CLR

Answer 2

Принятый ответ верен в отношении трех уровней безопасности, но неверен в отношении причины, по которой здесь требуется UNSAFE.

На самом деле задаются два вопроса:

1. Безопасно ли устанавливать сборки на PERMISSION_SET = UNSAFE?

   Независимо от того, о чем будут беспокоиться некоторые люди, в этом нет ничего изначально неправильного или «небезопасного»."с уровнем безопасности UNSAFE.Набор разрешений UNSAFE позволяет делать вещи, которые могут более легко поставить под угрозу безопасность и / или стабильность системы, но ничто не говорит о том, что функциональность всех , считающаяся "небезопасной", будет иметь либоэффект.И плохо написанные запросы / хранимые процедуры / функции могут отрицательно повлиять на производительность и стабильность системы.Тот факт, что какой-либо функцией можно злоупотреблять, не означает, что ее нельзя использовать правильно, чтобы делать удивительные вещи.

   Хост CLR SQL Server, который отделен от основного хоста CLR ОС Windows (и то, и другое есть или должно быть(отдельно от хоста ASP.NET CLR) строго ограничены и включают только небольшое подмножество .NET Framework.Включенные библиотеки (их можно найти здесь: Поддерживаемые библиотеки .NET Framework ) гарантированно будут работать через обновления SQL Server и обновления .NET Framework на уровне сервера (т. Е. Исправления, обновления,так далее).Существуют и другие библиотеки, которых нет в этом списке, и которые полностью «безопасны» для использования с точки зрения того, что они делают, но просто не входя в этот «поддерживаемый» список, их необходимо зарегистрировать как UNSAFE, поскольку они не имеютt был протестирован и не гарантирован для использования в обновлениях .NET Framework.Например, ServiceModel, я полагаю, была чистой библиотекой MSIL в .NET 2 и 3. Однако она стала смешанным режимом (то есть содержит некоторый неуправляемый код), начиная с .NET 4 и поскольку SQL Server 2012 и новее связаны между собойтолько для CLR v4, код веб-служб, написанный заново ServiceModel, который прекрасно работал в версиях SQL Server до версии 2012, перестал работать, начиная с версии 2012.

2. Почемуя могу получить сообщение об ошибке system.core , если я не установил сборку на PERMISSION_SET = UNSAFE?

   Эта проблема характерна для SQL Server2005. SQL Server 2005 был первой версией, включающей поддержку функциональности .NET (то есть SQLCLR).Библиотека System.Core не существовала в .NET Framework 2.0, а .NET Framework 3.0 не выпускалась до конца 2006 года (см. История версий .NET Framework ).Из-за этого времени System.Core не мог быть включен в хост CLR для SQL Server 2005. Но из-за .NET 3.0 и 3.5, использующих CLR v2, так же, как и .NET Framework 2.0, онможно использовать эту функциональность в SQL Server 2005 ЕСЛИ вы устанавливаете сборку на UNSAFE, что позволяет искать за пределами внутреннего хоста CLR SQL Server.

   SQL Server 2008 и 2008 R2 обавключили .NET Framework 3.5 в свой внутренний хост CLR, и они добавили еще две библиотеки в список «Поддерживаемых», одна из которых System.Core .Таким образом, для этих двух версий вы можете использовать функциональность System.Core в сборке SAFE.И именно поэтому System.Core находится внизу списка «Поддерживаемые библиотеки .NET Framework» (ссылка выше).

Для получения дополнительной информации.Нюансы NET, связанные с SQLCLR, см. В моей статье Лестница к SQLCLR Уровень 5: Разработка (Использование .NET в SQL Server) , а также вся серия " Лестница в SQLCLR " на SQLServer Central.

Для получения дополнительной информации о работе с SQLCLR в целом посетите: SQLCLR Info

Answer 3

Извините, что констатирую очевидное, но какую часть "UNSAFE" трудно понять?

Вы можете:

• уничтожить установку SQL Server и ОС
• ввести утечки памяти
• добавить нестабильность

Я предполагаю, что по вашему вопросу "Как заставить этот CLR работать с 2005?" где вы хотите использоватьметоды, которые могут иметь два последних побочных эффекта ...