The Joel on Software Discussion Group (CLOSED)

A place to discuss Joel on Software. Now closed.

This community works best when people use their real names. Please register for a free account.

Other Groups:
Joel on Software
Business of Software
Design of Software (CLOSED)
.NET Questions (CLOSED)
TechInterview.org
CityDesk
FogBugz
Fog Creek Copilot


The Old Forum


Your hosts:
Albert D. Kallal
Li-Fan Chen
Stephen Jones

Joel's IIS Bug

after sending your suggestion to Joel for personal gain, do you mind sharing your knowledge with us and make this world a better place? :)
Giacomo Lacava Send private email
Thursday, October 28, 2004
 
 
IIS is crap. It sould be called BCWS: BuggyCrappyWebServer.
a long timer BCWS user
Thursday, October 28, 2004
 
 
Run it on 2000...?
Mr Jack
Thursday, October 28, 2004
 
 
Important:
If you are upgrading to IIS 6.0, be aware that the upgrade process automatically configures IIS to use the default anonymous user account IUSR_ComputerName, where ComputerName is the local computer. If you have a domain-based anonymous user account, you must configure the anonymous user identity to use this same domain-based account after the upgrade.

IUSR_ComputerName

The IIS IUSR_ComputerName user account is for anonymous access to IIS. By default, when a user accesses a Web site that uses Anonymous authentication, that user is mapped to the IUSR_ComputerName account. IUSR_ComputerName has the following default user rights:
•    

Access this computer from a network (SeNetworkLogonRight)
•    

Bypass traverse checking (SeChangeNotifyPrivilege)
•    

Log on as a batch job (SeBatchLogonRight)
•    

Allow log on locally (SeInteractiveLogonRight)
Top of pageTop of page
IWAM_ComputerName

The IIS IWAM_ComputerName user account is for starting out-of-process applications in IIS 5.0 isolation mode. IWAM_ComputerName has the following default user rights:
•    

Replace a process-level token (SeAssignPrimaryTokenPrivilege)
•    

Adjust memory quotas for a process (SeIncreaseQuotaPrivilege)
•    

Bypass traverse checking (SeChangeNotifyPrivilege)
•    

Access this computer from a network (SeNetworkLogonRight)
•    

Log on as a batch job (SeBatchLogonRight)

Sounds to me like one of those privileges mentioned above is not associated with the account you are trying to use?
Pete Gilbert Send private email
Thursday, October 28, 2004
 
 
Shouldn't a decent piece of software complain instead of doing "what you probably wanted anyway". I mean, it's only a bit dubious if end-user software takes a "best guess" but you could expect administrators and developers to know exactly what they want.
Mystran
Thursday, October 28, 2004
 
 
I asked what would happen if he just nuked the IWAM_<MachineName> account, and also if the behavior is reproducable if the account is created on the local machine and not on the domain. IE, if its possible that one of the worker threads is trying to authenticate as the domain user, hitting some rediculously small timeout, and just defaulting to IWAM_<MachineName>.
John Christensen Send private email
Thursday, October 28, 2004
 
 
For a problem like this, I would use one of my MSDN support incidents.    (I've used about 3 in 10 years)

Have you done this Joel?
Will Dean
Thursday, October 28, 2004
 
 
Will,

Have you ever actually received a useful response when using an MSDN support incident?  So far, I've only actually met one person who has.  :)  That said, perhaps those of us in Canada aren't aggressive enough at escalating support requests when the people at the other end claim they don't know the answer.
Chris in Edmonton Send private email
Thursday, October 28, 2004
 
 
I have *always* (100% of 3 or 4 times) had good support from MS Dev support.  In the UK at least, they don't close the incident without asking you if you're happy with it being closed.

By the time I resort to calling MS, I am usually deep in kernel- (or at least WinDBG)-level anaylsis, and they've always provided someone who has sat on the end of the phone and worked on WinDBG with me, or they've taken huge crash-dump files, and returned complete, annotated, log files of the WinDBG analysis of them.

The end result tends to be that I get sent pactches and the support incident gets credited back to me.

I can't imagine what mechanism they use to just say 'don't know, shove off', after you've opened a support incident which is worth several hundred quid.  I've never had to be pushy about it.

If I get to the point that I think it's a bug in an MS product for which there's no publically available patch/documentation, then that's when I call.
Will Dean
Thursday, October 28, 2004
 
 
Shame Joel can't just crack open the source code and see what the problem is...

Thursday, October 28, 2004
 
 
Yeah.  I bet a quick glance at the IIS/COM+ source code would soon tell him that.
Will Dean
Thursday, October 28, 2004
 
 
Indeed, if a customer calls up IIS support that actually has workign knowledge of the process model, event logs, memory dumps, etc. They will go more than our of their way to help - it's refreshing not to have to take a few hours to do the cursory (see also: easy stuff) investigation.

It certinaly seems to be a bug - except that the bug is that the custom IUSR is running any threads at all - if the application is set to high, all threads should be running in the context of the identity set in COM+ (in this case, IWAM_whatever).

Open up a support incident w/ MS, it shouldn't take too long to escalate.
Greg Hurlman, MS IIS Support (NC), ret. Send private email
Thursday, October 28, 2004
 
 
So, I guess I got that one right... yay me.
Greg Hurlman, MS IIS Support (NC), ret. Send private email
Thursday, October 28, 2004
 
 
Yeah! Thanks Greg. Sorry, I wasn't paying attention to the newsgroups here.
Joel Spolsky Send private email
Thursday, October 28, 2004
 
 
I'm taking educated guesses at this point but I bet IIS creates the initial pool of threads that a website works off of, and gives them the configured identity.

As time goes on, however, those threads are recycled (this is a sticking point - does IIS 5.1 recycle worker threads, like IIS 6.0 does?) or new threads are created to meet demand. In this case, though, its the COM+ application that's creating new threads - since the COM+ application uses IWAM, it creates those threads under the IWAM identity.

The bug here, I think, is that the COM+ application, when created, should take the identity configured in IIS.
John Christensen Send private email
Thursday, October 28, 2004
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz