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?
>
>
> PerlOptions "My::AuthHandler My::C
"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
"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 imp
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
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 ca
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
especiall
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 us
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 th
"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
w
> "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 a
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?
>
>
> PerlOptions "My::AuthHandler My::ContentHandler My::Tran
> 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
"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 m
> "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 t
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 i
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 p
"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 u
"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 u
Adam Prime <[EMAIL PROTECTED]> wrote:
>The servers that had apache on them for users when i was at school didn't
>even allow normal cgi, so i have no idea how one would approach doing
>something like this with mod_perl.
Even more convoluted is when a user can ExecCGI, but only via suexec.
mod_p
> -Original Message-
> From: Adam Prime [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, November 16, 2000 11:46 AM
> To: '[EMAIL PROTECTED]'; [EMAIL PROTECTED]
> Cc: Geoffrey Young
> Subject: RE: security suggestion
>
>
> The servers that had a
> 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
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 s
Geoffrey Young wrote:
> maybe it would be possible to limit
>
> PerlAuthenHandler 'sub {do something desctructive};'
>
> via a directive, but this is mod_perl - I can't see how you would be able to
> allow good activity without there being some way around it for destructive
> types...
That's w
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 mov
> -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
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:
>
>
> arbitrary perl code...
>
I'd argue that peopl
At Doug's suggestion I'm moving a brief conversation we've had in private
to this list so others can get involved.
I've been following out the security implications of mod_perl here at
Brown University, and from what I can see, enabling it gives people the
same basic access privileges that ExecCG
Would it make sense to allow anonymous subroutines as handlers only if
ExecCGI is turned on for a given directory? (Likewise, allow handlers
only in modules residing in system directories unless ExecCGI is turned
on?)
--
Richard Goerwitz[EMAIL PROTECTED]
28 matches
Mail list logo
