"Richard L. Goerwitz" <[EMAIL PROTECTED]> wrote:
> Gunther Birznieks wrote:
>
> > ...I would advocate an ExecModPerl option or something like that so that
> > user's could not arbitrarily install their own Perl Handlers.
>
> If a user has ExecCGI privileges he or she can commandeer the most important
> part of the request cycle (the response phase), so I'm not sure we get
> better
> security or control by having a separate ExecModPerl option.
>
> NB: If we re-use ExecCGI for mod_perl, people will feel as though they're
> on familiar turf. Sysadmins will understand the implications of turning it
> on (i.e., they'll know that turning it on means the ability to execute code
> on the server, using the ID under which Apache runs). And re-using ExecCGI
> would relieve us of having to reserve another (mostly redundant) word.
I don't think it's redundant at all. In fact it is already possible to configure a
Location or VirtualHost section within a mod_perl server in which mod_perl
functionality is disabled (or overridden) with an old-style ExecCGI directive (scripts
fork into separate SUID user-owned processes). In that scenario, which is not as
unlikely as it might at first seem, for an ISP, the directive ExecCGI already has
meaning, and "reusing it" would cause some bad ambiguouity.
-dave
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
