Aaron Trevena wrote:
[...]
http://www.bytemark-hosting.co.uk do some good deals and discounts for
free software author and seem nice people.
Please submit ISPs that support mod_perl and/or virtual servers. so we can add
them to:
http://perl.apache.org/help/isps.html
I've added the one mentioned
Perrin Harkins wrote:
On Wed, 2003-06-11 at 12:58, Mike Zelina wrote:
I couldn't find any documentation on how a host *could* provide mod_perl
and do it in a way that would be safe for his server and usable for a
client.
I was just talking about this with my co-workers. Here's one way:
Set up
On Wed, 2003-06-11 at 12:58, Mike Zelina wrote:
> I couldn't find any documentation on how a host *could* provide mod_perl
> and do it in a way that would be safe for his server and usable for a
> client.
I was just talking about this with my co-workers. Here's one way:
Set up a front-end apache
On Wed, 2003-06-11 at 18:09, Sidharth Malhotra wrote:
> Not quite a manual, but read some of these discussions on PerlMonks:
>
> http://www.perlmonks.org/index.pl?node=mod+perl+isp+host&go_button=Search
> "mod_perl shared hosting"
> "ISPs supporting mod_perl"
> "mod_perl: the bane of share webhost
Not quite a manual, but read some of these discussions on PerlMonks:
http://www.perlmonks.org/index.pl?node=mod+perl+isp+host&go_button=Search
"mod_perl shared hosting"
"ISPs supporting mod_perl"
"mod_perl: the bane of share webhosting"
Hope this gives you some answers (not a lot of hope, though)
We use BSD::Resource for our mod_perl clients. Keeps them
from eating the machine alive.
On another shared machine each client gets their own
interpreter with some pretty tight limits on child
spawning, open children etc. on top of the Resource limits
Shared hosting mod_perl is a real drag to
> I am in front of a security issue. We are running several site using
> modperl. Last days, a hacker used a script to call some script of our
sites
> for bad purpose. He needed to be authenticated, but we are only using
> session cookies. Then, once he was loged in, he could retrieve this id
and
Try this.
http://www.snert.com/Software/mod_throttle/
Tor.
fred wrote:
> Hi,
>
> I am in front of a security issue. We are running several site using
> modperl. Last days, a hacker used a script to call some script of our sites
> for bad purpose. He needed to be authenticated, but we are only
I've had people run password guessing scripts and stuff.
I've handled it on a case by case basis, ie, limit the number
of wrong guesses.
There are a bunch of modules that can set limits as well which
can come in handy against very brutish sorts of misuses of your site,.
I used mod_throttle.c, t
Matt Sergeant ([EMAIL PROTECTED]) said something to this effect on 03/02/2001:
> ...now that I've developed applications that make rather extensive
> use of the Apache API, I would actually love to have an environment
> similar to CGI but providing the full Apache API, including logging,
> notes/p
On Thu, 1 Mar 2001, [EMAIL PROTECTED] wrote:
> > I used to believe that too, but now that I've developed
> > applications that make rather extensive use of the Apache API, I would
> > actually love to have an environment similar to CGI but
> > providing the full
> > Apache API, including logging
> > And forking a new process under mod_perl
> > really defeats the purpose.
>
> Does it?
Well I confess I just assumed.
> I used to believe that too, but now that I've developed
> applications that make rather extensive use of the Apache API, I would
> actually love to have an environment s
> >
> > > This is a general Unix webserver issue and not specific to
> > > mod_perl, so I've marked your message [OT] for off-topic.
> >
> > Well, workarounds are available for specific webserver environments, so I
> > don't believe it's an inappropriate question.
> >
> > With CGI, you use the
On Thu, 1 Mar 2001, [EMAIL PROTECTED] wrote:
>
> > This is a general Unix webserver issue and not specific to
> > mod_perl, so I've marked your message [OT] for off-topic.
>
> Well, workarounds are available for specific webserver environments, so I
> don't believe it's an inappropriate questi
> This is a general Unix webserver issue and not specific to
> mod_perl, so I've marked your message [OT] for off-topic.
Well, workarounds are available for specific webserver environments, so I
don't believe it's an inappropriate question.
With CGI, you use the suexec mechanism to start execu
Stas Bekman wrote:
> On Wed, 28 Feb 2001, Gustavo Vieira Goncalves Coelho
Rios wrote:
> > the key user\password are kept inside this file, so
anyone can uses an
> > editor to retrieve the user mysql account. I resolve
this problem
> > running php on secure mode and chgrping the php file
th
Vladimir Ivaschenko wrote:
>
> Take a look at http://www.freevsd.org. I haven't used it personally, but
> it looks like something that you need..
> This system is a based on making a chroot environment for each user with
> his own apache and everything.
>
i can vouch for this approach to develo
Take a look at http://www.freevsd.org. I haven't used it personally, but
it looks like something that you need..
This system is a based on making a chroot environment for each user with
his own apache and everything.
Gustavo Vieira Goncalves Coelho Rios wrote about "security!":
> After some tim
Probably a stupid question, but wouldn't named virtuals solve this problem?
I'm not all that familiar with MySQL, but we have a similar set up here with
slightly different technology - Solaris, Netscape Enterprise Server, and
Oracle. I should think that you could replicate this using BSD, Apache,
On Thu, 1 Mar 2001, Gunther Birznieks wrote:
> mod_perl 2.0
>
> At 10:33 PM 2/28/2001 -1000, Kee Hinckley wrote:
> >-BEGIN PGP SIGNED MESSAGE-
> >Hash: SHA1
> >
> >At 9:44 AM +0800 3/1/01, Stas Bekman wrote:
> > >At this moment anybody who has an access to mod_perl server can read any
> >
mod_perl 2.0
At 10:33 PM 2/28/2001 -1000, Kee Hinckley wrote:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA1
>
>At 9:44 AM +0800 3/1/01, Stas Bekman wrote:
> >At this moment anybody who has an access to mod_perl server can read any
> >data which is accessible by the same server. suexec is not an
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
At 9:44 AM +0800 3/1/01, Stas Bekman wrote:
>At this moment anybody who has an access to mod_perl server can read any
>data which is accessible by the same server. suexec is not an option
>because of process persistance.
I suspect this is why it is v
On Wed, 28 Feb 2001, Gustavo Vieira Goncalves Coelho Rios wrote:
> Hi folks!
>
> I have a FreeBSD server configured as a http server, running apache.
> This installation includes mod_perl+EmbPerl, mod_php4 mod_cgi and
> mod_fastcgi. Some of my users will be using mysql for database. The
> problem
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 moving a brief conversation we've had
>i
> -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 people shouldn't be able to do that -
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]
On Tue, 19 Sep 2000, Richard Goerwitz wrote:
> I can certainly understand why someone would want to keep Registry
> or Embperl-enabled scripts in directories reserved for trusted sys-
> tems people.
>
> But it shouldn't be a tremendously big deal to allow people to use
> pre-written modules usin
At 10:25 AM 4/28/00 +0100, Matt Sergeant wrote:
>On Fri, 28 Apr 2000, Marc Slemko wrote:
>
> > On Thu, 27 Apr 2000, Matt Sergeant wrote:
> >
> > > Unfortunately there's also a browser bug to contend with. They treat \x8b
> > > (I think that's the right code) as < and there's a similar code for
> >
On Fri, 28 Apr 2000, Marc Slemko wrote:
> On Thu, 27 Apr 2000, Matt Sergeant wrote:
>
> > Unfortunately there's also a browser bug to contend with. They treat \x8b
> > (I think that's the right code) as < and there's a similar code for
> > >. Since most web developers are just doing s/ > attacks
On Thu, 27 Apr 2000, Matt Sergeant wrote:
> Unfortunately there's also a browser bug to contend with. They treat \x8b
> (I think that's the right code) as < and there's a similar code for
> >. Since most web developers are just doing s/ attacks based on character sets like this. Sad, but true. Ev
On Fri, 28 Apr 2000, Gerald Richter wrote:
> >
> > Gerald, what about Embperl, does it escape \x8b?
> >
>
> No, there is no html escape for \x8b (and I guess the other one Matt
> mentioned is \0x8d for >) I know, so Embperl will not escape it, but this
> could be simply change by an entry in epc
>
> Gerald, what about Embperl, does it escape \x8b?
>
No, there is no html escape for \x8b (and I guess the other one Matt
mentioned is \0x8d for >) I know, so Embperl will not escape it, but this
could be simply change by an entry in epchar.c. Any suggestion to what this
should be escaped? Then
Matt Sergeant writes:
> Unfortunately there's also a browser bug to contend with. They treat \x8b
> (I think that's the right code) as < and there's a similar code for
> >. Since most web developers are just doing s/ attacks based on character sets like this. Sad, but true. Even our loved
> C
Jeremy Howard wrote:
> I'm interested in providing 'HTML email' support for my users
> (like HotMail, Outlook Express, Eudora 4.0, etc provide), but
> I'm very nervous about security. Essentially, providing HTML
> email involves letting any arbitrary HTML get displayed by Apache...
I've been
Matt Sergeant writes:
> Unfortunately there's also a browser bug to contend with. They treat \x8b
> (I think that's the right code) as < and there's a similar code for
> >. Since most web developers are just doing s/ attacks based on character sets like this. Sad, but true. Even our loved
> C
On Thu, 27 Apr 2000, John M Vinopal wrote:
> I am a bad hacker and watching your line. I see cookies A and B go to you.
> I set cookies A and B in my web browser. I am now you. You can try to
> permute the cookies with IP# (breaks on proxies) or Browser type, but all
> cookie based approaches
I am a bad hacker and watching your line. I see cookies A and B go to you.
I set cookies A and B in my web browser. I am now you. You can try to
permute the cookies with IP# (breaks on proxies) or Browser type, but all
cookie based approaches believe in the value of something sent cleartext.
O
On Thu, 27 Apr 2000, Vivek Khera wrote:
> > "SC" == Steven Champeon <[EMAIL PROTECTED]> writes:
>
> SC> developers and designers) for Webmonkey:
>
> SC> http://hotwired.lycos.com/webmonkey/00/18/index3a.html
>
> SC> If you want to see what sort of stuff the XSS problem opens you up for,
>
On Thu, 27 Apr 2000, Vivek Khera wrote:
> > "SC" == Steven Champeon <[EMAIL PROTECTED]> writes:
>
> SC> developers and designers) for Webmonkey:
>
> SC> http://hotwired.lycos.com/webmonkey/00/18/index3a.html
>
> SC> If you want to see what sort of stuff the XSS problem opens you up for,
>
On Thu, 27 Apr 2000, Vivek Khera wrote:
> Why on earth would you take user input and output it verbatim to your
> pages? Rule number 1 of developing a web site is to never trust the
> user's input values. *Always* validate it against what you're
> expecting.
I guess someone had better tell the
> "SC" == Steven Champeon <[EMAIL PROTECTED]> writes:
SC> developers and designers) for Webmonkey:
SC> http://hotwired.lycos.com/webmonkey/00/18/index3a.html
SC> If you want to see what sort of stuff the XSS problem opens you up for,
SC> just try appending ?tw=alert("aha!"); to the URL abo
On Thu, 27 Apr 2000, Marc Slemko wrote:
> > Can you be more specific about why you say that? If I set an encrypted,
> > short-lived cookie upon validated authentication, why is that any less
> > secure than any of the other approaches you mentioned?
>
> It isn't necessarily any "less secure", but
On Thu, 27 Apr 2000, Nick Tonkin wrote:
> On Thu, 27 Apr 2000, Marc Slemko wrote:
>
> > Cookies are not secure and will never be secure. They may be "good
> > enough", and you may not have much choice, but they are still simply not
> > secure when you put everything together.
>
> Can you be mo
On Thu, 27 Apr 2000, Marc Slemko wrote:
> Cookies are not secure and will never be secure. They may be "good
> enough", and you may not have much choice, but they are still simply not
> secure when you put everything together.
Can you be more specific about why you say that? If I set an encrypt
On Thu, 27 Apr 2000, Jeremy Howard wrote:
> I'm interested in providing 'HTML email' support for my users (like
> HotMail, Outlook Express, Eudora 4.0, etc provide), but I'm very
> nervous about security. Essentially, providing HTML email involves
> letting any arbitrary HTML get displayed by Apa
69 matches
Mail list logo
