At 08:42 AM 11/20/00 -0500, Richard L. Goerwitz wrote:
>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.
I don't think that this is the case if you configure apache to use suexec
option. With suexec, the CGI script a user invokes cannot even run with
the permissions of the web server, it runs with the permissions of the
individual user. No scripts can trample over each other (other than a
denial of service on CPU and disk) maliciously. But if you open up
mod_perl, then you give the user power over the entire web server including
the prospective capability to hijack another user's URLs.
I do believe there would be ISPs that would enable CGI and special mod_perl
handlers, but not want to enable a user installing their own handlers.
>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 am not sure I agree that ExecCGI gives similar power as mod_perl based on
the argument of suexec behavior.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
