On Tue, 2002-03-26 at 12:14, James Lum wrote: > Folks, > 1st, I want to thank you all for your responses and > clarifications about 'suid perl' and 'mod_perl' and the > way they work together. It is kinda like I suspected. :( > > 2nd, I should have worded my real question a little > differently. Basically, it is: > > How can I get perl code, invoked by the Apache web server, > to: > 1. create/write/read files that have the ownership of > the owner of the perl code. (Apache suexec) > 2. execute with the best performance. (mod_perl) > > Since Apache suexec and mod_perl do not work together, > my alternatives are: > 1. - Configure Apache WITHOUT suexec and WITH mod_perl. > - Invoke 'suid perl' for the perl program. > - Have the 'suid perl' program be owned by a non-root userid > which is the owner of the program. > - Convert the 'suid perl' program to meet mod_perl requirements. > OR > 2. - Run a separate Apache web server that supports only > a single domain or userid. > - Run the separate Apache web server with a userid that is > the same as the owner of the perl script. > - Configure the separate Apache server WITH mod_perl and > WITHOUT suexec. (suexec is not needed) > - mod_perl the perl program. > OR > 3. - Lobby to get Apache suexec and mod_perl to work together.
You can lobby all you want, but suexec and mod_perl will never work together using Apache 1.3. This is not for lack of want, but because of the way Apache 1.3 is designed. However, Apache 2.0 will support this type of configuration. You can create pools of apache processes that all run as different users. From my limited knowledge of Apache 2.0, this is done by pre-forking serveral servers that each run multiple threads. So you could have a pool of processes that use mod_perl, and another pool without mod_perl for serving static content. Or in your case, you could have several pools of mod_perl servers running as different users. I have been aching to try apache 2.0, but I haven't found time to get around to it. Please note that Apache 2.0 is still considered Beta quality and not recommended for production use. Of course, a beta release from the Apache group is worth a final release from most software vendors :) For more info on Apache 2.0 look at the apache.org website, and for info on mod_perl 2.0, search the mailing list archives. Stas has sent off several messages explaining where to get the new mod_perl 2.0 code... Cees > OR > 4. - ???? > > Which choice gives me the best of all worlds? .... the world > in which: > - a user's cgi program can create/write files that are > owned by the owner of the cgi program > - and has the performance of compiled code > - and does not complicate or slow down the web server > - and does not use too much of the system resources > - and is not overly complicated for the programmer > - and is not overly complicated for the web admin > > I don't want much ... do I ;=) > > jim > > > "Randal L. Schwartz" wrote: > > > >>>>> "Jim" == Jim Smith <[EMAIL PROTECTED]> writes: > > > > Jim> Basically, mod_perl can run scripts in the same manner as any other > > Jim> unix program. > > > > Maybe we're getting hung up on details, but "mod_perl" is not a "unix > > program". It's a module for Apache. Therefore, "in the same manner" > > is no longer applicable. > > > > mod_cgi forks to run processes. > > > > mod_perl doesn't fork. > > > > mod_perl can run Perl code via the embedded Perl interpreter, and this > > interpreter can cause a fork. But mod_perl doesn't inherently fork at > > all. > > > > And the distinction is important, especially in the context of > > this discussion (setuid with "mod_perl"). > > > > -- > > Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 > > <[EMAIL PROTECTED]> <URL:http://www.stonehenge.com/merlyn/> > > Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. > > See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! >
