Sni.dll not included in .NET Core 3.x.x shared folder

[RomBrz]

We are using .NET Core in our applications, but with .NET Core 3.x.x we start to have problems that "sni.dll missing". Seems like when using it, the library put the sni.dll inside of the code itself, and this give me problems as we use the security recomendations to use permissions as little as possible (Read Only with Application Pool Identity), so the application in 3.x.x crashes as it try to execute the dll.

In .NET Core 2.x, when you install a Server Bundle, sni.dll comes with the Core as "shared dll", so any process could execute there. In .NET Core 3.x didn't come.

Workound: i copied the sni.dll from "C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App\2.2.8" to "C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App\3x.x" and the applications running .NET Core 3.x.x could run with "Read Only" permission on project folder (the same behavior that works with 2.x.x projects).

I already opened this issue in .NET Core git, but they told me that is a SQL thing
dotnet/aspnetcore#18266

[cheenamalhotra]

In .NET Core 2.x, when you install a Server Bundle, sni.dll comes with the Core as "shared dll", so any process could execute there. In .NET Core 3.x didn't come.

Hi @RomBrz

.NET Core 3.x onwards the new SqlClient library "Microsoft.Data.SqlClient" is used, and it is certainly not the same as before since SNI.dll are now referenced from external packages. But I'm a little confused how SNI.dll was integrated before and shipped with ASP.NET Core App.

@ajcvickers
Could you shed some light on how System.Data.SqlClient and SNI.dll were included before in the working ANC.App v2.2.8 (C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App\2.2.8) as I'm looking at SNI.dll and System.Data.SqlClient.dll properties and are they .NET Framework DLLs?

In order to understand which SNI.dll library is getting pulled for Microsoft.Data.SqlClient now, I need some background of how ASP.NET integrates with SqlClient.

[cheenamalhotra]

@RomBrz

I think you might also need to migrate to the new namespace "Microsoft.Data.SqlClient" in order to work with ASP.NET Core 3.x, if not done yet. If your code still references System.Data.SqlClient, that could be the reason it looks for sni.dll in the loaded runtime libraries and works when copied manually.

@ajcvickers please correct me if I'm wrong.

[RomBrz]

Hi @cheenamalhotra , thanks for helping me with that.
We are using Microsoft.Data.SqlClient in all our .NET Core 3.1 projects, and we're having the same problems, as Microsoft.Data.SqlClient searches for sni.dll in the same folders as System.Data.SqlClient.

My problem is related with permissions and availability of the DLLs. Let my try to explain better:

Before .net core 3.0 there were a sni.dll in C:\Program Files (x86)\dotnet\shared\Microsoft.AspNetCore.App\2.2.8, for example, and when i install that on my server, this folder by default has basicaly "Read and Execute" permission for almost everyone, so any application could execute any DLL that exists in this folder. With .NET Core 3.x, the sni.dll don't existis in this shared folder, and the code put that sni.dll in it's own folder.

Let me exemplify the default behavior:
App1 running with .NET Core 2.1.15:
C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App\2.1.15\sni.dll (folder with Read and Execute permission)
C:\Inetpub\App1 (folder with Read only)
The application runs fine with Read only permission, as App1 try to find and execute sni.dll from shared folder.

App2 running with .Core 3.1.1:
C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App\3.1.1\sni.dll (folder with Read and Execute permission) DON'T EXIST
C:\Inetpub\App2\runtimes\win-x64\native\sni.dll was created when building the project
C:\Inetpub\App2 (folder with Read only)
The application don't run, as i need to give "\native" Read and Execute permission to run.

So with the .NET Core 3.x behavior i have more insecure applications as, to work, i have to give more NTFS permissions to run the "same" code.

My workaround is simply get the sni.dll and put inside the C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App\3.1.1\sni.dll, so the App2 in my example will run with "Read Only".

Seems like with .NET Core 3.x Microsoft choose to not use sni.dll as a "common dll that should be in default shared dlls" and who wants to use it should put inside your code (and with that opening a security flaw as giving NTFS permission to Execute inside a code isn't a best practice).

TL: sni.dll come in .NET 2.x shared folder when you install the server bundle. .NET 3.x didn't come with sni.dll in shared folder, forcing who want's to use to publish inside the project's folder, and with that forcing to give more permissions that should be needed to run compared with an 2.x project.

[ajcvickers]

@cheenamalhotra With regard to the SNI dependency, this isn't something I am very familiar with. It is likely something that @danmosemsft's team knows more about. @bricelam might also have some ideas.

With regards to using ASP.NET Core 3.x, yes, that requires updating to "Microsoft.Data.SqlClient". (This is, of course, assuming that you're using some part of ASP.NET Core that does data access, such as Identity or EF.)

[danmoseley]

I wasn't aware of any change to sni.dll deployment between 2.1 and 3.1. Maybe @ericstj can recall.

[ericstj]

We've never included sni.dll in Microsoft.NETCore.App. This has always shipped as a dependency of the SqlClient package: https://www.nuget.org/packages/runtime.native.System.Data.SqlClient.sni/

It looks like ASP.NET core previously included SqlClient in Microsoft.AspNetCore.App, but then removed it in 3.0. That's the reason for this observed change.

It was brought in by Microsoft.EntityFrameworkCore.SqlServer and Microsoft.Extensions.Caching.SqlServer, so the changes to these two components in 3.0 are what caused the removal of sni.dll from the AspNetCore shared framework.

[RomBrz]

Is there a way to solve this? What is the permission recomendations for running a in proc asp.net core site in iis?
I like to suggest asp.NET Core team do something (as .NET Core still a "new thing") about this "breaking changes" (i don't know if this should be the place, but..):

1. How about define what should be the minimum permission needed to run asp.NET Core applications?
2. Considering that this is defined and should be the default, how to deal with this kind of problems?
   .NET Core should be (for what i've heard) making version upgrades less problematic.. but a simple change from .NET 2.2.8 to 3.0.0 caused me two big breaking changes on hosting:
   a) A common dll, to most of my applications, to comunicate with SQL Server just "gone" from it's default behavior;
   b) The first breaking change approach, to put the dll inside the code folder, gave me the second breaking change: my published code just stopped working with "Read Only" permission.
   c) With a few exceptions, majority of the systems that i manage on many servers (.NET 2.0, .NET 4.0, .NET Core 2.0, .NET Core 3.0) always run with "Read Only" permission on respective App Pool Identity user. This is the best secure practice from Microsoft... Why don't keep this approach (very secure) with future .NET Core versions (in case, mandatory for library design).

[cheenamalhotra]

Hi @RomBrz

Related question I had for you.. how to do you usually manage permissions for Dependent DLLs that are loaded by NuGet packages referenced?

The change of package from System.Data.SqlClient > Microsoft.Data.SqlClient seems to be the motivation to remove SNI.dll from shared libs, as Microsoft.Data.SqlClient is now an independent library but also needs to reference SNI.dll from another NuGet package in order to work.

[RomBrz]

Hi! @cheenamalhotra
The "default behavior" for all of ours applications is to use "Read Only". Each project we start with a website created at IIS, with respective application pool using "AppPool Identity" mode, and with "IIS AppPool\APPPOOLNAME" NTFS permission at home directory for the site.
Some legacy projects buit in 2005-2010 for example, using .NET 2.0 or even 4.0, was made executing dlls or writing something in disk, so we have some folders in these projects with "Read and Execute" or even "Modify".
More recently, for what i can record, we had problems when "Roslyn" start to need "Execution" permissions. I than give "Execute" to the HOME/bin/roslyn/csc.exe (with everything else working with Read only), but after a time the developers start to use it with another way that didn't need more this permission.
With .NET Core, all projects by default works with Read only permission to entire folder. For what i understood talking with the devs, seems like some libraries made this need to "execute dlls".
Than, we start to have problems with some projects asking for more permissions (after my investigation, i come with some projects needing "Traverse" permission on home directory only, instead of just "Read only" to home and entire folder.
Seems like sni.dll works in different way, asking more components and permissions.. Than it works fine until devs starts to work with .NET Core 3.0.
As i told, by "default" i would need to give Execution to the dll folder at each .NET Core 3.0 projects, but i discover that by design the .NET Core try to find dlls on shared folder, so right now to keep the projects with Read only i was copying manually the "sni.dll" from .NET Core 2.x folder to the 3.0.x and 3.1.x folders, and thinking that i would change the Release pipeline on Azure DevOps eventually to made every project that need one DLL to copy that "at each release" to the shared folder, if more projects and more libraries start to ask Execute permission.
We use here the .NET Core "In Process", handled by IIS 10 (Win 2019).
The last recomendation i get from Microsoft is to keep minimium permissions, so the minimum should be for me Read only at home directoly only (each project with it's own exclusive permission it it's own home folder so if i ever try to change AppPools will give permission denied).

[simonauner]

We're seeing the same issue with a .NET Core 3.1.101 project, using Microsoft.EntityFrameworkCore 3.1.2 and Microsoft.EntityFrameworkCore.SqlServer 3.1.2, built on Ubuntu 18.04 (both on my local machine and on Azure Pipelines Virtual Machines (link to machine spec: https://github.com/actions/virtual-environments/blob/master/images/linux/Ubuntu1804-README.md)).

System.TypeInitializationException : The type initializer for 'Microsoft.Data.SqlClient.TdsParser' threw an exception.
  ----> System.TypeInitializationException : The type initializer for 'Microsoft.Data.SqlClient.SNILoadHandle' threw an exception.
  ----> System.DllNotFoundException : Unable to load shared library 'sni.dll' or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: libsni.dll: cannot open shared object file: No such file or directory
   at Microsoft.Data.ProviderBase.DbConnectionPool.TryGetConnection(DbConnection owningObject, UInt32 waitForMultipleObjectsTimeout, Boolean allowCreate, Boolean onlyOneCheckConnection, DbConnectionOptions userOptions, DbConnectionInternal& connection)
   at Microsoft.Data.ProviderBase.DbConnectionPool.TryGetConnection(DbConnection owningObject, TaskCompletionSource`1 retry, DbConnectionOptions userOptions, DbConnectionInternal& connection)
   at Microsoft.Data.ProviderBase.DbConnectionFactory.TryGetConnection(DbConnection owningConnection, TaskCompletionSource`1 retry, DbConnectionOptions userOptions, DbConnectionInternal oldConnection, DbConnectionInternal& connection)
   at Microsoft.Data.ProviderBase.DbConnectionInternal.TryOpenConnectionInternal(DbConnection outerConnection, DbConnectionFactory connectionFactory, TaskCompletionSource`1 retry, DbConnectionOptions userOptions)
   at Microsoft.Data.ProviderBase.DbConnectionClosed.TryOpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory, TaskCompletionSource`1 retry, DbConnectionOptions userOptions)
   at Microsoft.Data.SqlClient.SqlConnection.TryOpen(TaskCompletionSource`1 retry)
   at Microsoft.Data.SqlClient.SqlConnection.OpenAsync(CancellationToken cancellationToken)
--- End of stack trace from previous location where exception was thrown ---
   at Microsoft.EntityFrameworkCore.Storage.RelationalConnection.OpenDbConnectionAsync(Boolean errorsExpected, CancellationToken cancellationToken)
   at Microsoft.EntityFrameworkCore.Storage.RelationalConnection.OpenDbConnectionAsync(Boolean errorsExpected, CancellationToken cancellationToken)
   at Microsoft.EntityFrameworkCore.Storage.RelationalConnection.OpenAsync(CancellationToken cancellationToken, Boolean errorsExpected)
   at Microsoft.EntityFrameworkCore.Update.Internal.BatchExecutor.ExecuteAsync(IEnumerable`1 commandBatches, IRelationalConnection connection, CancellationToken cancellationToken)
   at Microsoft.EntityFrameworkCore.Update.Internal.BatchExecutor.ExecuteAsync(IEnumerable`1 commandBatches, IRelationalConnection connection, CancellationToken cancellationToken)
   at Microsoft.EntityFrameworkCore.ChangeTracking.Internal.StateManager.SaveChangesAsync(IList`1 entriesToSave, CancellationToken cancellationToken)
   at Microsoft.EntityFrameworkCore.ChangeTracking.Internal.StateManager.SaveChangesAsync(DbContext _, Boolean acceptAllChangesOnSuccess, CancellationToken cancellationToken)
   at Microsoft.EntityFrameworkCore.SqlServer.Storage.Internal.SqlServerExecutionStrategy.ExecuteAsync[TState,TResult](TState state, Func`4 operation, Func`4 verifySucceeded, CancellationToken cancellationToken)
   at Microsoft.EntityFrameworkCore.DbContext.SaveChangesAsync(Boolean acceptAllChangesOnSuccess, CancellationToken cancellationToken)

dotnet --info outputs the following:

→ dotnet --info
.NET Core SDK (reflecting any global.json):
 Version:   3.1.101
 Commit:    b377529961

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  18.04
 OS Platform: Linux
 RID:         ubuntu.18.04-x64
 Base Path:   /usr/share/dotnet/sdk/3.1.101/

Host (useful for support):
  Version: 3.1.1
  Commit:  a1388f194c

.NET Core SDKs installed:
  2.2.402 [/usr/share/dotnet/sdk]
  3.0.102 [/usr/share/dotnet/sdk]
  3.1.101 [/usr/share/dotnet/sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.2.8 [/usr/share/dotnet/shared/Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.2.8 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.0.2 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.1 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.2.8 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.0.2 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.1 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

I tried to install Microsoft.Data.SqlClient 1.1.1 and the 2.0.0-preview1.20021.1, but that didn't help.

Please let me know if I can help out by providing more information or trying out different packages.

I have another project running with the same packages on Ubuntu, but without saving or reading data with EF Core, just using EF for migrations, and in that project we don't see any of the above issues.

[cheenamalhotra]

Hi @simonauner

The driver shouldn't be loading sni.dll on Ubuntu in any case 😟
Can you provide us a repro app that we can try? Have you also tried on any other linux machine and do you hit the same problem?

[simonauner]

Hi @cheenamalhotra

Yes, the other machine being the CI machine for Azure Pipelines (I linked the machine specs in my previous post).

I'll try to setup a minimum reproducible repo and get back to you.

[simonauner]

I've tried to setup a basic repo that mimics the failing repo of ours, but everything seems to be working fine. My guess is that something we do in the DBContext setup messes it up. Can't find the issue at the moment though.