On Fri, 17 Nov 2000, mgraham wrote:
Maybe another approach would be to explicitly list the handlers that
are allowed to be used in any given context. Kind of
like 'Options', but for perl handlers. Something like 'PerlOptions',
perhaps?
Location /users
PerlOptions
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
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
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
"Richard L. Goerwitz" [EMAIL PROTECTED] wrote:
Gunther Birznieks wrote:
...I would advocate an ExecModPerl option or something like that so that
user's could not arbitrarily install their own Perl Handlers.
If a user has ExecCGI privileges he or she can commandeer the most important
"Gunther Birznieks" [EMAIL PROTECTED] wrote:
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
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
I think Randal was making a similar point I was making last night (SG
time). That as long as you execute Perl code, you can manipualte the memory
space of Perl (and hance change the behavior of Apache::Registry).
But you explained it in your reply to me. Basically you want explicit
handlers
I think these are good points.
However, to some degree, if this is an attempt to allow an ISP protection,
it's not because most ISPs offer CGI access to their customers.
In addition, the moment you give mod_perl access to a developer they have
the rights to do a LOT of stuff that goes beyond
Gunther Birznieks wrote:
It seems to me that mod_perl wasn't really designed for safety against your
own developers
I accept this point. But it's really beside _my_ point, which was that
mod_perl modules can offer critical added functionality to run-of-the-mill
web publishers (whether it
"Richard" == Richard L Goerwitz [EMAIL PROTECTED] writes:
Richard I simply want to be able to do the same thing in Perl with mod_perl. I
Richard want to be able to give developers ("users" - whatever you want to call
Richard them) added functionality, without giving them the ability to execute
"Randal L. Schwartz" wrote:
Use Template Toolkit, and disable the "EVAL_PERL" option for their space.
Set up Plugins and Filters that call your Cool Perl Code.
Then they write arbitary text files to be delivered...
Suppose it were possible to set Perl-based modules to work the same way
C
I'd have no problem if mod_perl was set up to turn off
PerlSetEnv, lit-
eral 'sub { ... }' handlers, Perl sections, and the use of
Perl modules
in non-system paths (except where ExecCGI is turned on).
Maybe another approach would be to explicitly list the handlers that
are allowed to be
mgraham wrote:
Maybe another approach would be to explicitly list the handlers that
are allowed to be used in any given context. Kind of
like 'Options', but for perl handlers. Something like 'PerlOptions',
perhaps?
Location /users
PerlOptions "My::AuthHandler My::ContentHandler
"Richard" == Richard L Goerwitz [EMAIL PROTECTED] writes:
Richard That's a neat idea.
Richard The only quibble I can think of is that this doesn't go far enough.
Richard This lower level of privilege we're talking about is one in which -
Richard 1) Only specific Perl modules are available
"Randal L. Schwartz" wrote:
I think y'all are missing it. As soon as I have any Perl code access
via Apache::Registry or anything like that, I can do this:
*Apache::Registry::handler = \my_trojan_horse;
Can you explain in what server-configuration context the above directive
would
Following up on the security suggestion (I'm actually responding to
private mail, so I'll just quote the person who wrote to me without
giving a name) -
Of course you can do this in an .htaccess file, too:
Perl
arbitrary perl code...
/Perl
I'd argue that people shouldn't be able to do
-Original Message-
From: Richard L. Goerwitz [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 16, 2000 10:11 AM
To: [EMAIL PROTECTED]
Cc: Geoffrey Young
Subject: Re: security suggestion
Following up on the security suggestion (I'm actually responding to
private mail, so
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
Maybe it's just me, but it seems that the responses richard has gotten
haven't really touched on the core of the problem. That mod_perl isn't
exactly friendly to sysadmin's who want to run apache on a (i'm guessing),
student accessed server, with user dir's and all that other stuff. I'm
pretty
The thing is, though, that as a web administrator I don't want those
same developers (or at least all of them) to be able to create and in-
stall _arbitrary_ handlers or arbitrary perl code. Sometimes the de-
velopers just don't know enough. And sometimes I just don't trust
them enough to
"Adam Prime" [EMAIL PROTECTED] wrote:
Maybe it's just me, but it seems that the responses richard has gotten
haven't really touched on the core of the problem. That mod_perl isn't
exactly friendly to sysadmin's who want to run apache on a (i'm guessing),
student accessed server, with user
22 matches
Mail list logo
