Unnecessary access request to drive root

[CoskunSunali]

Having an Asp.Net 5 application hosted on Windows Server 2012 R2 (possibly others?) requires one to assign read access to drive root C:\ in some cases.

The issue occurs when the IIS application pool is set to use a custom user. ApplicationPoolIdentity does not have such a problem.

Assigning full access to approot, wwwroot and logs folders does not fix the issue.

The IIS Platform Handler running has version 1.2.

The stdout file contains an error stating that the access was denied but does not provide any details on to which path.

A screenshot showing access request to the drive root C:\ can be seen below:

There seems to be other people having the same issue which we have been discussing on issue #449

[Tratcher]

Hmm, I'm not reproducing this on Win10. Can you give more details about your custom app pool identity setup?

[Tratcher]

Oh, and what version of DNX and tooling you're using?

[recalde]

I'm also getting this is on 2012 R2 with custom app pool identity using beta8 x64 and tooling. I also have an application setup in a virtual directory using the .Configure1(..) workaround (not sure if that has anything to do with it.)

@Tratcher, make sure the I'd you use is not an admin.

[CoskunSunali]

The build is using runtime version dnx-clr-win-x86.1.0.0-rc1-15838

The tooling I have on my build computer is Beta 8. However, the web server does not have any tooling installed.

This is how I prepared my server:

1. Install HttpPlatformHandler 1.2.
2. Publish the website on file system.
3. Deploy it to the server.
4. Create a website on IIS and set its path to the wwwroot of the publish output (*** see below).
5. Set the application pool's CLR version to "No managed code"
6. I made sure that the website has HttpPlatformHandler module enabled on IIS.

Unfortunately I cannot give any specific information about the custom identity; it is created automatically using Plesk. However, I might try to answer your questions if you would like me to check and report some specific info about the user.

By the way, the website I am trying to run is at https://github.com/csunali/WebApplication2ForKestrel

[CoskunSunali]

Additionally, I don't have any virtual directories or Configure1 methods as @recalde mentions. Just, pure Web Application template (beta 8) and just a regular IIS website, with No managed code option chosen.

[CoskunSunali]

As @recalde stated, please make sure that the identity you use is not an administrator on your Windows 10 setup.

In addition to administrators, having it as a regular user would also allow him to access C:\, afaik.

So, please setup a user that has minimum access rights and does not have permission to any other folder than wwwroot, approot and logs.

That is how we setup our users, since we provide hosting services and we don't want people to access folders outside their websites.

[pakrym]

@csunali, @recalde did you tried updating to rc1? Does the issue still reproduce?

[pakrym]

Closing this, if this issue still exists please ping me.

[ghost]

@pakrym, I am having the same problem as @csunali in a similar configuration: Windows 2012 Server using dnx-clr-win-x86.1.0.0-rc1-final with Plesk and a custom identity.

Running web.cmd directly starts kestrel without problems. Running under the custom identity fails unless I give it write permissions to the root folder where the application is located (in my case D:\).

[provatidis]

@pakrym, I can confirm the same problem (Windows 2012 R2 Server, plesk, custom identity) using dnx-clr-win-x86.1.0.0-rc1-update1. It works If I change the Identity of the pool to an administrator account which has access to C:\

[CoskunSunali]

@pakrym, Sorry, was not able to respond to you earlier.

Yes, as other people also stated, the problem still occurs.

It is also very easy for you to test it. Forget about Plesk and just use a custom identity in your IIS application pool. Make sure that the custom identity does not have access to drive C and is not in Administrators role.

[pakrym]

I was able to reproduce the issue and have some details.

Access denied. comes from running cmd, even if current user has access to file that is being executed by cmd /c list access is required all the way up to drive root by interpreter itself.

This problem will go away after switching to dotnet

[CoskunSunali]

@pakrym, Please excuse my ignorance. What do you mean by switching to dotnet? Are you talking about the target framework monikers? E.g.: dotnet5.4.

P.S.: Are those monikers changing again with the RC2?

[pakrym]

I mean dnx to dotnet cli (http://dotnet.github.io/) migration, the way applications would be built and packaged would eliminate cmd along with access issue.

[CoskunSunali]

Sounds great. Do you have an idea when should we expect that change? I mean, I guess you are already working on it but is it expected to be released along with the RC2 release?

[pakrym]

Yep, RC2 is exactly when the switch happens.

[CoskunSunali]

Thanks for the confirmation (and the information)!

I have one last question. I am currently already using RC2 dev bits to build non-production test applications. Does it actually mean that I am already using that "dotnet" thing instead of the dnx thing? I guess no because of the VS ASP.NET Tooling being RC1, right?

[pakrym]

No, you are still using dnx/dnu bits if you're not specifically use console and dotnet * commands.

[CoskunSunali]

Thank you again. Very much looking forward for the final RC2 release.

Cheers!

[CoskunSunali]

@pakrym Is there an issue where I can follow up with the new implementation? E.g. dotnet * commands, how to use them, etc. I feel kind of lost :/

[pakrym]

Not an issue per-se but there is a repo https://github.com/dotnet/cli/