* Lee E. Brotzman wrote on Sat, May 25, 2002 at 11:20 -0400: > On Fri, 24 May 2002 18:38:42 BST, Glynn Clements said: > > I don't know about other Unices, but Linux deliberately doesn't > > support setuid scripts (a wise move, IMHO). Perl attempts to > > re-introduce the problem via the setuid "suidperl" binary, but many > > sysadmins will disable that (again, a wise move, IMHO). > > I write almost all my CGI in Perl and indeed the setuid Perl scripts are run by > suidperl. This gives me the "taint" feature whereby I must untaint any user > input -- a good feature, but certainly no cure-all. > Note that if you use suEXEC to invoke a setuid Perl script, you > will lose the tainted-data feature. man perlrun /-T I don't see why someone would suEXEC setuid perl scripts. SuEXEC already does setuid to the owner of that script - and I think it may even refuse execution if setuid bits are set. At least SuExec makes some tests, check docs. > Another reason I don't like suEXEC. I'd prefer the script bombs > if I try to use untested external data. Maybe you're just using it wrong. SuExec forces that users can do CGI scripting, but in their own "user space" with their usual persmissions. And users are usually not allowed to set uid somethink (at least on unix). But all of set uid is not the purpose of SuExec. SuExec "simulates" the behavior if any user had it's own Webserver with their uid running, but in fact you need a wwwrun server only. This even works well for virtual servers running on different users. oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
This archive was generated by hypermail 2b30 : Wed May 29 2002 - 11:08:10 PDT