Perhaps you ought to gfind a way to use Safe; then?
>-----Original Message-----
>From: Richard L. Goerwitz [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, November 16, 2000 9:09 AM
>To: mod_perl list
>Subject: security suggestion
>
>
>At Doug's suggestion I'm moving a brief conversation we've had
>in private
>to this list so others can get involved.
>
>I've been following out the security implications of mod_perl here at
>Brown University, and from what I can see, enabling it gives people the
>same basic access privileges that ExecCGI does. How does it do this?
>Well, for one thing, you can inject arbitrary Perl code at any stage in
>the Apache request cycle by using a literal
>
> PerlWhateverHandler 'sub { ... }'
>
>in an htaccess file. You can also specify
>
> PerlWhateverHandler
>Some::Arbitrary::Path::To::An::Arbitrary::Module.pm
>
>I've been thinking that, since giving users the ability to do these
>things is essentially like giving them ExecCGI privileges, that these
>things should only be allowed where the ExecCGI option is turned on.
>
>There's also the problem, if a person can ExecCGI, that they can then
>use Apache (), and then access all dir_config, notes, and
>other settings.
>At times it may be useful for a systems administrator to create private
>dir_config variables that run-of-the-mill CGI scripts simply can't see.
>
>These are two separate issues, of course.
>
>The more pressing one, I think, is the first, namely that we need to
>tie the ability to use arbitrary Perl subroutines and arbitrary Perl
>modules (i.e., modules in non-system paths) to the ExecCGI option.
>
>I realize that forcing us all to turn ExecCGI on for directories where
>we want to use arbitrary Perl subroutines would be a bit of a pain at
>this point. So for the current 1.24_0x series I'd suggest adding some
>new "paranoid" compile-time option that would deny arbitrary subs and
>modules in non-system paths unless ExecCGI is enabled. Another idea
>that I haven't really thought through would be to create some new
>PerlLiteralSubs On|Off directive that could not be overridden once
>turned on.
>
>For the future, though, it might be useful to tie arbitrary subs and
>the ability to use Perl modules to ExecCGI. ExecCGI-like privileges
>something a sysadmin should always have to decide to do. My sense is
>that they should never be turned on implicitly, e.g., by simply adding
>and enabling a module.
>
>Does this make sense to anyone else?
>
>--
>Richard Goerwitz
>[EMAIL PROTECTED]
>
