Geoffrey Young wrote:
> maybe it would be possible to limit
>
> PerlAuthenHandler 'sub {do something desctructive};'
>
> via a directive, but this is mod_perl - I can't see how you would be able to
> allow good activity without there being some way around it for destructive
> types...
That's where I disagree. Perl modules often offer extremely useful
functionality. They often do things that even ordinary web developers
might want to do. So I think it's imperative that ordinary web devel-
opers be able to install canned mod_perl handlers that I've written
for them (or installed for them).
The thing is, though, that as a web administrator I don't want those
same developers (or at least all of them) to be able to create and in-
stall _arbitrary_ handlers or arbitrary perl code. Sometimes the de-
velopers just don't know enough. And sometimes I just don't trust
them enough to allow it.
But that doesn't mean I want to cut them off from modules I've made
available myself.
Think of it as being like C modules. Say I want to give them access
to a built-in counter module. I compile the C module and either load
it dynamically, or build it statically into Apache and enable it.
Either way, they get access to the counter module's functionality.
But the don't, as a side-effect, get to execute arbitrary C code.
Perl modules should work the same way. I should be able to give them
access to existing modules without giving them access to Perl. If I
want to give them access to Perl, I should have to do it explicitly.
I've advocated co-opting ExecCGI for this purpose.
We could go the mod_include route, of course, where you get #exec
by default, and only lose #exec via IncludesNoExec.
That could work, too.
> PERL_SECTIONS=0 at build time can deactivate this across the board
IMHO it shouldn't be an all-or-nothing thing.
--
Richard Goerwitz [EMAIL PROTECTED]
