In the context of what you are talking about, I think giving ExecCGI
permissions should not allow them to change mod_perl handlers or do
anything to adjust mod_perl either. ExecCGI is a lot less problematic than
exposing access to mod_perl from a shared web server security standpoint
especially if CGI's are suexec'ed.
So I would advocate an ExecModPerl option or something like that so that
user's could not arbitrarily install their own Perl Handlers.
At 12:20 PM 11/19/2000 +0000, Richard Goerwitz wrote:
>Gunther Birznieks wrote:
>
> > The CGI scripts on your site would not be passed through Apache::Registry
> > or Apache::PerlRun, they would run as normal CGIs. No? So that makes sense
> > as a motivation to allow mod_perl on a server for content handlers that are
> > tightly defined. But don't allow the users access to anything else in
> mod_perl.
>
>Precisely.
>
>I feel as though I've been explaining myself poorly because I've been so
>widely misunderstood.
>
>But what you said above about sums it up. I'm only talking about giving
>people access to specific mod_perl modules (or to modules in very specific
>places). I don't want to give people blanket Apache::Registry access as
>part of that package (except in cases where I specifically say so).
>
>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>)
>
>Re (1) above, I wonder whether it matters if modules I allow load modules
>that I _don't_ allow. My sense is that as long as I can control the ini-
>tial loading, I don't care whether the thing that's loaded runs amok. It
>is my responsibility (if I allow access to a module) to make sure that
>module will behave itself.
>
>Those more versed in security issues will perhaps want to think this
>through.
>
>I've been receiving a steady trickle of off-list mail, by the way, from
>ISPs and webmasters/sysadmins working in organizations where you just
>can't allow everyone CGI access (or full mod_perl/Perl access) - but where
>it would be very useful to allow people selective access to specific
>Perl modules.
>
>They are excited by the thought that they could offer new functionality
>(and added value) to their services, without necessarily having to trust
>all their web users (publishers, web developers - whatever) enough to
>allow them to execute arbitrary Perl code.
>
>Those of you who are working on your own, or in small/controlled shops,
>may not have an intuitive grasp of the circumstances the rest of us work
>under. But if you think about how things must be for us (some of us w/
>hundreds, if not thousands, of web developers), you'll see that we can't
>monitor every account and audit every change. Universities with lots of
>student workers/accounts are classic cases. Students are smart and mis-
>chievous, and they come and go regularly. They make web pages and sys-
>tems, and they do the same part-time for departments and workgrous with-
>in the institution. We may want to give them access to a specific Perl
>module (e.g., some institution-wide authentication system that's imple-
>mented with a PerlAuthenHandler). But we certainly don't want giving
>them that sort of access to open up a floodgate by allowing them to exe-
>cute arbitrary Perl code on the server - unless we say so (e.g., by giv-
>ing them ExecCGI permission).
>
>--
>
>Richard Goerwitz
>PGP key fingerprint: C1 3E F4 23 7C 33 51 8D 3B 88 53 57 56 0D 38 A0
>For more info (mail, phone, fax no.): finger [EMAIL PROTECTED]
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
__________________________________________________
Gunther Birznieks ([EMAIL PROTECTED])
eXtropia - The Web Technology Company
http://www.extropia.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
