Gunther Birznieks wrote:
> >At the risk of repeating myself, I'm looking for a way of setting up mod_
> >perl so that, if I turn off ExecCGI for a given directory (and maybe spe-
> >cify a list of Perl modules or paths), it will mean that, as far as mod_perl
> >is concerned,
> >
> > 1) users can only use specific modules (or modules in specific places)
> > 2) users can't (by implication) use Apache::Registry unless I say so
> > 3) users can't change PERL5LIB or use PerlSetEnv (or PerlPassEnv)
> > 4) users can't include any Perl code indirectly or otherwise (e.g.,
> > <Perl> sections, literal 'sub { ... }'s as handlers)
>
> ...I would advocate an ExecModPerl option or something like that so that
> user's could not arbitrarily install their own Perl Handlers.
Some thoughts:
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.
--
Richard Goerwitz [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
