By default .NET applications (EXEs) that are launched from a remote file system (eg \\server\bin\SomeApp.exe), will not be considered trusted and typically will fail (unless specifically designed to run with low trust). This is in direct contrast with unmanaged applications which always give full trust to launched programs, regardless of location. From a quick search, I know many of you have run into this issue and have found some work arounds.
The .NET runtime team is considering changing this behavior so that managed applications act just like unmanaged one in this respect. We believe that it will not decrease security, but there is risk and effort required for any change and would like feedback on its likely usefulness to customers.
A) Have you ever run into this limitation (a security exception when running a .NET application from a network file share)?
B) How often do you use network file shares for deploying applications (managed or otherwise)?
C) If you think we should make this change, when would be a good time? Is it something we should do sooner in a service pack of the .NET Framework or later in a full release of the framework. Note, we are DONE with .NET Framework 3.5, so there is zero chance it is getting in that release.
D) Can you ask your local network admin what they think of this issue? Would they be in favor of this sort of change? If so, when?
Please comment on this post, link back to your post or send me an email!
I passed the early feedback around the CLR team, and they suggested I added some clarification on the propsosed change...
1) The change we are considering is best thought of not a change in policy, but rather new evidence associate with launching an EXE. This new evidence would only exist if a managed EXE was loaded by the win32 CreateProcess API direct. Thus it does NOT affect hosted scenarios (eg web browsing on the Intranet).
2) We believe that this will NOT reduce security in any meaningful way because when you launch an EXE off a file share, you ARE trusting the file share. That EXE can be unmanaged code, and as such it has the ability to do ANYTHING the current user can do. Thus disallowing managed EXEs (but continuing to allow unmanaged EXE to launch), does not serve a useful security purpose.
I hope that helps...
Update (8/13/2008): Thanks to your feedback, we just enabled .NET EXEs to run off a network share in SP1.