Kinook Software Forums

Go Back   Kinook Software Forums > Visual Build Professional > [VBP] General Discussion

Reply
 
Thread Tools Rate Thread Display Modes
  #1  
Old 07-27-2007, 04:36 PM
martys martys is online now
Registered User
 
Join Date: 06-09-2006
Posts: 24
More ASP.NET problems

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)

Last edited by martys; 07-27-2007 at 04:43 PM.
Reply With Quote
  #2  
Old 07-27-2007, 08:00 PM
kinook kinook is online now
Administrator
 
Join Date: 03-06-2001
Location: Colorado
Posts: 5,758
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/micro...s&rnum=3&hl=en
[3] http://msdn.microsoft.com/msdntv/tra...ranscript.aspx
Reply With Quote
  #3  
Old 07-29-2007, 11:06 PM
martys martys is online now
Registered User
 
Join Date: 06-09-2006
Posts: 24
Thanks for all the help! I'll try implementing some of these suggestions as soon as I can.
Reply With Quote
  #4  
Old 07-30-2007, 10:46 AM
kinook kinook is online now
Administrator
 
Join Date: 03-06-2001
Location: Colorado
Posts: 5,758
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).
Reply With Quote
Reply

Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



All times are GMT -5. The time now is 10:51 PM.


Copyright 1999-2019 Kinook Software, Inc.