views:

325

answers:

2

I have implemented tracing based on System.Diagnostics.

I am also using a System.Diagnostics.TextWriterTraceListener, and hooked the whole trace up to a MOSS 2007 Web Application.

The trace for some reason is trying to (a) create the log file, and/or (b) write to the log file using the user that is currently browsing the SharePoint site , is there any way to configure the logging to use a particular user account instead?

A: 

Please don't tell me this is necessary - http://www.15seconds.com/Issue/040511.htm?voteresult=5

Michael L
Its not, but its one of the ways to do this
Will
+1  A: 

Obviously MOSS is configured to use windows authentication (kerberos) and imersonation. If you don't need to impersonate the current user logged into moss, turn off impersonation (its in web.config). You'll find that the log files will be created and written by the user under which your moss installation's application pool is running.

If you HAVE to use impersonation, then another solution is to give everyone rights to create and write files in the log directory (and ONLY in the log directory). This isn't exactly the best idea, however. You can disallow the read permissions for everybody but those that need to read the logs, but you still will have to worry about people trying to DoS you by filling up the disk.

The third choice is to, before you log, switch identities. Something like this might work:

var wic = WindowsIdentity.Impersonate(IntPtr.Zero); // "revert to self"
/* LOG GOES HERE K */
wic.Undo(); // return to impersonation

BIG CAVEAT: I'm just learning this stuff myself, so the above code may not work at all. If it does, its sweet because you won't have to p/invoke to log in your log-writing-identity, which also means you won't have to create that user and store their password in cleartext in your application.

I wonder where's the ol' Skeeter on this one? Windows security requires some heavy lifting; I'm just starting with the bar right now...

Will
liked your answer a lot, I think impersonation has to stay because this is the way MOSS checks internal authorizations to moss related content (lists,documents, pages,etc), but it looks like I need to write an ExecuteWithElevatedPrivileges function.
Michael L
You don't have to elevate, you just have to reverberate. that is't right, but it rhymes. You can switch out of impersonation using the code sample I gave (IT IS NOT PRODUCTION WORTHY! Read up on it!) to drop back to the ASP.NET worker process' identity while you log.
Will
That way you only have to set configure the acl's for one user.
Will