What access does a Windows authenticated user in T-SQL need to create an External_Access or Unsafe Assembly? - sqlclr

Question

I'm trying to do a POC using Sqlclr and C# to call .Net code (dll) from a stored procedure. I'm trying to write to EventLogs. I was able to create a safe assembly and then create a stored procedure wrapper around my dll. But while executing the code it failed - for Event Log access the Assembly needs to be created with an External_Access/ Unsafe permission set.
When I tried the same with an External Assembly it didn't work. So I went with the route of creating a Login from the signed dll.
I signed the dll using Visual Studio. Under project properties signing tab, I signed it without a password (snk file).
I then created an asymmetric key in sql with the dll.
Using this asymmetric key I have created a Login in Master.
I then granted this Login External Access Assembly.
Changed Database to use the particular one in which I am trying to create the wrapper procedure
In the next step I tried to create the Assembly with External_Access
permission set.
This failed with the Error Message -
Msg 300 -
External Access Assembly Permission was denied on object 'server', database 'master'
I then tried going through the route of setting Database Trustworthy
to ON just to check if the concept actually works.
This failed with the same exception.
My question is does my Windows authenticated login need to have more permissions to be able to set the External_Access permissions. Does it require an SA account?

Answer 1

First of all, did you mean to run this on master (as per the error message)?
To use TRUSTWORTHY, the user needs sysadmin as per here, but it is generally a bad idea to use TRUSTWORTHY.
To create an assembly with EXTERNAL_ACCESS the login needs EXTERNAL ACCESS ASSEMBLY permission on the server. To create the assembly as UNSAFE the login needs UNSAFE ASSEMBLY permission on the server. You can read more about that here.
Niels

Answer 2

It would help greatly to know what version of SQL Server you are using given that there was a rather significant change, security-wise, in SQL Server 2017 as it relates to creating Assemblies. I have written a series of articles explaining the overall issue in SQL Server 2017 and providing a few solutions that can be automated within Visual Studio / SSDT:
SQLCLR vs. SQL Server 2017, Part 1: “CLR strict security” – The Problem
Part 1 is mostly explanation while parts 2 and 3 are the two methods for working within these constraints.
If you are using SQL Server 2017, have you tried granting the Asymmetric Key-based Login the UNSAFE ASSEMBLY permission?
Did you do anything else besides GRANT EXTERNAL ACCESS ASSEMBLY for that Login? Did you DENY anything?
Another thing to try is to add the Asymmetric Key-based Login to the sysadmin fixed server role:
ALTER SERVER ROLE [sysadmin] ADD MEMBER [{LoginName}];
While this shouldn't be necessary, the older documentation (2008 R2 and before) stated that it was a requirement. I have never needed to do it, but it is worth testing as it if nothing else works, it will get us closer to the actual issue. Be sure to set TRUSTWORTHY back to OFF in the DB where you turned it ON.
Also, you might want to review the series of articles I wrote on SQL Server Central that explain various aspects of working with SQLCLR in general:
Stairway to SQLCLR