More ASP.NET problems

[martys]

I'm running into more problems running the project from ASP.NET. I call:

bld.SyncBuildEx(true, ident.Attributes["userName"].Value, "", ident.Attributes["password"].Value, false, false);

with good values for the userName and password (specifically, the username is "nt", just so we're clear). This user has permissions to edit files in a certain directory. However, when I run a step to edit a file in that directory, it fails with a "Access Denied" error. I added a Run Script step to show the username it's running under, and it says it's running under "Network Service". Is this to be expected? I would think it should be running as the user specified in the call to SyncBuildEx

Specifically, this is a Write XML step. I noticed that a Write Text step does not cause the same problem. (Also, this is the updated Write XML step that disables DTD verification)

[kinook]

You didn't indicate how you're logging the username, but the value of the USERNAME system macro depends on the identity of the thread that instantiated the Application object (since it currently initializes the value when created), not the identity of the build thread. By default, IIS 6 ASP.NET Web applications run in the security context of the NetworkService account [1].

Now, the build thread itself (and actions such as the Copy Files and Write File actions) will either run under the identity of the calling thread (if the first parameter of SyncBuildEx is true) or the identity of the calling process (if false), while other processes that are started by calling RunProgramEx (Run Program, SourceSafe, etc.) will run under the identity specified in the SyncBuildEx call.
http://www.visualbuild.com/Manual/syncbuildexmethod.htm

There does seem to be something a bit odd going on with the Write XML action. Since it is implemented as script code, it gets executed in the context of a COM apartment-threaded helper component. I suspect that COM is creating a compatible thread for this component, and the identity of this thread (where the script code executes) is that of the calling process (since this is what happens for threads created by a thread that is running impersonated unless special steps are taken [2]). We'll investigate to see what can be done about this. One workaround might be to force the IIS process to run under an identity with the necessary privileges [3].

Another alternative would be to instead invoke the VBP console app to build (the no wait method demonstrated in the WebLauncher sample). Since that process gets created with the proper identity and no impersonation occurs, both the build thread and all processes created by it will run under the specified identity. This method could be performed synchronously as well (for instance, waiting for the process to complete while populating the response page with stdout) or asynchronously, returning as soon as the process was started (in this case a link could be provided to the build log file or another file that is periodically updated with build progress).

[1] http://support.microsoft.com/kb/317012/
[2] http://groups.google.com/group/microsoft.public.platformsdk.win_base_svcs/browse_thread/thread/60175a8d042ea332/fba8e19cdbd8e3d1?lnk=st&q=createthread+security+context+process&rnum=3&hl=en
[3] http://msdn.microsoft.com/msdntv/transcripts/20031120ASPNETEOTranscript.aspx

[martys]

Thanks for all the help! I'll try implementing some of these suggestions as soon as I can.

[kinook]

We did find a bug in VBP v6.3+ which caused the problem with the Write XML and other script actions running with the wrong identity under ASP.NET. The main download at http://www.kinook.com/Download/VisBuildProEval.exe has been updated with a fix for this issue (VisBuildBld.dll v6.4.0.5).

Also, my earlier statement regarding USERNAME was not entirely accurate. The USERNAME system macro is derived from the equivalent environment variable, and environment variables are based on the identity of the ASP.NET worker process when it is started (and are not altered by Windows with each identity switch).