Error, resurrection of an old "EPERM: operation not permitted, lstat ..." error in Node 10 #9109
Description
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?