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]
