27/03/2006, 18:35
|
| | | Fecha de Ingreso: noviembre-2005
Mensajes: 658
Antigüedad: 19 años Puntos: 3 | |
| Esto dice
Configuring IIS 6.0 Application Pools to run CGI scripts
I'm writing this more as a reference to myself than anything else after I keep getting stuck on doing permissions correctly on IIS 6.0 servers for high-security (e.g., independant application pools for worker processes) on CGI (e.g., ActivePerl) application. I'm going to do this briefly because I'm somewhat pressured for time now, and hopefully I'll understand my own notes later to fatten this up. Questions and comments are welcome.
We must make a new user, and note the password. password should not expire. user should be removed from users group and added to IIS_WPG group (contains default permissions needed to be a worker process). Make sure user doesn't have rights to terminal services, no interaction with user shell, and no remote access (VPN, dial-in, etc). If you're using Vis Studio with remote debugging, add the user to the Debugger Users group.
Create a new application pool. In the Identity tab, change the user to the user you created. Now under the "home directory" tab in the normal IIS web properties, change to the new application pool.
This is all that's needed for normal ASP process seperation.
For Perl, install ActivePerl. If you don't (or ActivePerl doesn't give you the option to do so), go to Allowed Web Services in IIS Admin. Click Add, set the service name to Perl CGI and the allowed files to: C:\Perl\bin\perl.exe "%s" %s (note the " " and change the path as needed - duh!) Mark it as allowed. In the application, go to Configuration (near application pool selection) and make sure cgi and/or .pl extensions are in the list. if not, click add, enter the extension, the same executable as before, use verbs GET,HEAD,POST (use others if you need it, of course) and leave script engine and check file exists checked. The application will only need scripts (not execute) on the execute permissions tab since we marked perl as a script engine above.
Now comes the tricky part: in addition to the obvious execute permission our user needs on the CGI files, our users need permission to launch the files (eg, worker process thread must launch external perl.exe process). I'll be verbose here to let search engines find this easier:
I get a 403.19 message from IIS with CGI
See below
I get "CGI Access Forbidden" message from IIS
Actually, the message you'll see in the browser is just "403: Access denied - You are not authorized to view this page" which never fails to throw me off course. Whenever you get an error in IIS, always look it up in the access log. There you'll see the minor error code. For example:
2005-03-01 09:39:27 127.0.0.1 GET /test.pl - 80 - 10.201.1.17 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1;+.N ET+CLR+1.1.4322) 403 19 1314
That's MSIE getting this error. To solve it, go to the local security policy. Under "User Rights Assignment", find "Replace a process-level token" and "Adjust memory Quotas for a Process" and add your user to both. On the file system, make sure that your user has read permissions (and execute on perl!) which it should by default unless you did weird permissions
That should be it - Windows is annoying sometimes. I've done this by the book and still managed to get weird errors sometimes. But then I'd do the same thing again, and eventually it would work (with new users, new app poolsm etc). But I never had to do anything beyond this. Happy scripting! |
