Following up on the security suggestion (I'm actually responding to
private mail, so I'll just quote the person who wrote to me without
giving a name) -
> Of course you can do this in an .htaccess file, too:
>
> <Perl>
> arbitrary perl code...
> </Perl>
I'd argue that people shouldn't be able to do that - unless, of course,
they can ExecCGI.
The general idea is this: Regular users without ExecCGI may have good
reason to say things like,
PerlAuthenHandler Apache::SomeNewAuthModule
E.g., suppose you want them to be able to use some local secure cookie-
based auth handler. Or they may want to use a locally written response
handler that converts HTML to XHTML on the fly - or innumerable other
modules.
Although we want those users to have access to these modules (and to the
added functionality they bring), we may not want them to be able to
execute arbitrary Perl code.
And if we DO want them to execute arbitrary Perl code, we should have
to explicitly grant them permission to do it. Permission shouldn't be
granted implicitly by doing something else (e.g., by enabling another
module like mod_perl).
My sense is that the existing ExecCGI mechanism is a perfectly reasonable
way of handling the permissions here, since being able to execute arbi-
trary Perl code is basically the same as ExecCGI privileges (it's a bit
more powerful, but why introduce more options if we don't really need
to?).
--
Richard Goerwitz [EMAIL PROTECTED]
