Error, resurrection of an old "EPERM: operation not permitted, lstat ..." error in Node 10

[new-mikha]

Describe the bug

The bug is pretty much the same as the one from the older JavaScriptServices repo:
aspnet/JavaScriptServices#1101

In a typical IIS deployment, the application runs as a user that only has permission to read the filesystem at the level of the application and below. It does not usually have permission to read any attributes of ancestor-level directories.

This causes Node to throw an error when it tries to load any module.
...

A patch has been applied earlier in the JavaScriptServices repo to fix this problem, and it worked well until some newer version of Node 10 (for me all works well with Node 8, but doesn't work with Node 10). The patch is still alive in the current repo, just turns to be not suitable for Node 10.

To Reproduce

Steps to reproduce the behavior: same as in the bug referenced above, just with the latest Node 10. I saw it when was using UseSpaPrerendering, in a new mvc/angular app generated by "dotnet new angular", with the SSR turned on, hosted under IIS in a folder with read/execute permissions for the hosting process identity, but with no permissions for this identity higher in the folder path.

The dotnet SDK version is 2.2.105.

The error as shown in the exception page:

NodeInvocationException: Prerendering failed because of error: Error: EPERM: operation not permitted, lstat 'C:\Temp'
at Object.realpathSync (fs.js:1456:7)
at toRealPath (internal/modules/cjs/loader.js:203:13)
at Function.Module._findPath (internal/modules/cjs/loader.js:256:24)
at Function.Module._resolveFilename (internal/modules/cjs/loader.js:579:25)
at Function.Module._load (internal/modules/cjs/loader.js:508:25)
at Module.require (internal/modules/cjs/loader.js:637:17)
at require (internal/modules/cjs/helpers.js:22:18)
at findBootModule (C:\Users\DefaultAppPool\AppData\Local\Temp\2rkofydm.er4:111:17)
at findRenderToStringFunc (C:\Users\DefaultAppPool\AppData\Local\Temp\2rkofydm.er4:116:28)
at renderToStringImpl (C:\Users\DefaultAppPool\AppData\Local\Temp\2rkofydm.er4:75:51)
Current directory is: C:\Temp\angular\aspnet-core-angular-ssr\bin\Release\netcoreapp2.1\publish
Microsoft.AspNetCore.NodeServices.HostingModels.HttpNodeInstance.InvokeExportAsync<T>(NodeInvocationInfo invocationInfo, CancellationToken cancellationToken)

Here's how it looks like in the Node debugger.

This is the execution stopped at the point where the patch from aspnet/JavaScriptServices#1102 been applied earlier. In AspNetCore repo it currently sits in the PatchModuleResolutionLStat.ts and entrypoint-http.js files, here is how it looks in the debugger:

As you can see above, it expects an exception to be thrown from the original lstat, and is ready to do the patching logic in catch.

However, in Node 10 the errors are not reported from bindings.lstat the expected way anymore. Instead, the error code goes into the errno field in the ctx parameter:

... and then the error is thrown from the function called later:

So the error happily avoids the patch, and is thrown, and Node can't do SSR in an AspNetCore app :-/

Unfortunately, it seems that the Node guys are not going to do anything with that. At least in 2013 they've put WONTFIX to the corresponding bug on their side, and as I understand that was it ever since:
nodejs/node-v0.x-archive#3977

With the JavaScriptService patch stopped working, the SSR scenarios are hardly workable under Node 10, unless the permissions are changed all the way up in the installation path. But the latter often is just not an option.

I'd say that the old patch needs to be updated?

[mkArtakMSFT]

@ryanbrandenburg can you please check whether we broke something recently or not?

[mkArtakMSFT]

If not, then this is not something we'll do in the near future as we have much more important areas for now.

[ryanbrandenburg]

@mkArtakMSFT I don't think this is our break. As @new-mikha pointed out, we did a hack/patch to make this work in more scenarios, but it seems that hack doesn't work for Node 10. The problem here is on the Node end, so continued fiddling from our side to try to force it to work are unlikely to succeed long term. The best advice I can give is to try what was suggested in that thread, like run your process as Administrator or try downgrading to Node 8.

[mkArtakMSFT]

Hi. Thanks for contacting us.
We're closing this issue as there was not much community interest in this ask for quite a while now.
You can learn more about our triage process and how we handle issues by reading our Triage Process writeup.