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...