* Lee E. Brotzman wrote on Wed, May 29, 2002 at 17:28 -0400: > On Wed, 29 May 2002 11:04:30 +0200, Steffen Dettmer said: > > 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. > > outweigh the risk of running all CGI programs with a real userid. Of the 30 or > so CGI programs in the project, only 8 had to have any elevated privilege. The > rest were just fine running as user "web" or whatever the web server UID was. This is not the problem! The reason for SuExec is quite different. If you have multiple (human) users on the same web server, you cannot allow that all that scripts run as the same wwwrun or nobody user. In this case the script from user A could read a script from user B and could overwrite logfiles from a script from user C, since all of them run as nobody (or whatever). > the same UID as the web server. I think you're better off if there are no files > owned by the UID of the web server, whether that's 'nobody' or some other > special-purpose UID. Well, but the files created by the scripts will be owned by that UID, and if a CGI script can read some file, any user of that server that is allowed to have CGI scripts can read it. This is the issue SuExec was made for. > I would hope that others would recognize that there are also > reasons *not* to use it. Yes, there are, but I think in such cases this will also work with suExec. So we just it everywhere, just to go for sure :) And if later some user get's allowed to make CGI scripts, he can do. oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
This archive was generated by hypermail 2b30 : Tue Jun 04 2002 - 20:33:57 PDT