According to Microsoft's SQL Programmability & API Development Team Blog, the Execute permission for CLR assemblies actually has no effect. To reduce confusion over this, the ability to grant execute permissions to assemblies has be removed from SQL Server 2005 SP 2.
A quick glance at MSDN doesn't indicate that the permission doesn't actually do anything, so many developers and administrators may have been misled.
According to RaviR,
As we shipped SQL Server 2005, this permission set was supported in TSQL but never enforced. So you could say "deny execute on assembly" but nothing happened. With this fix to revert the support from TSQL, you will not be misled anymore and we wanted to get this fix to you in a service pack of the same product that introduced you this immensely easy way of expressing your logic in assemblies. Going forward, with database upgrades to next release, any lingering assemblies that display this permission will be automatically corrected. And so you don't have to worry about a thing.
He continues by saying that security should be enforced using the CLR's security model. Chris Leonard responds
True, but this could be problematic for database security. In general, DBAs must not assume that developers understand security as it will be implemented in the database. However, developers may be involved in creating CLR assemblies that will be registered in the database. Assembly-level permissions give (or would have given) the DBA an appropriate level of granularity for enforcing appropriate permissions in the database instance. Would this really be so hard to implement? I don't think that pushing database-level security into the CLR is going to be a good idea. It certainly won't help Enterprise-Level DBAs (who are already cautious about SQL-CLR, frequently for good reasons) to become more eager to implement CLR support in their databases.
InfoQ Asks: Do you feel that the CLR security model sufficient for securing assemblies accessible from SQL Server?
