You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Stas Bekman <st...@stason.org> on 2001/03/01 02:44:47 UTC
Re: security
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 is that this scenario requires sensitive information inside
> file. This means no problem when these users write their dymanic pages
> inside a compiled program. I can chmod a-rw and nobody will be able to
> take away user/password from a compiled program. The problem happens
> when write their php or embperl pages!
>
> 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 the same user as
> the http process and removing other flags file access (g-rwx). So nobody
> besides the owner of the file (or the http process) will be able to read
> it.
>
> since php have some security facilities, like: if the file owner id !=
> the file the script is trying to open => fails.
> My problem is with perl: how to solve such a problem in a perl
> environment?
> Does mod perl allows any kind of security, to prevent ones writing
> script to read others files?
>
>
> PS: All cgi runs through suexec, so even cgi are not able to run the
> script, ok?
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 understand that you want to store the SQL engine authentication info,
and users not to know each other's access credentials. The only solution
at this point is to either trust your users not to abuse each other, or
run a separate server for each one :(
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://apachetoday.com http://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: security
Posted by Stas Bekman <st...@stason.org>.
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
> > >data which is accessible by the same server. suexec is not an option
> > >because of process persistance.
> >
> >I suspect this is why it is very easy to find hosting providers who
> >provide PHP, and not as easy to find providers who support Embperl,
> >Mason or other mod_perl solutions. Is there any effort to deal with
> >this? (Per-virtual-server-process-sharing, with the option of
> >dropping to zero processes, seems like a good start.) I'd really
> >like to see languages like Embperl stand a better chance going
> >head-to-head against PHP. It's very annoying to be able to whip
> >together a great solution for my own servers, only to have to
> >implement it for one of my clients in PHP, without nearly the power
> >that Perl gives me.
See http://perl.apache.org/~dougm/modperl_2.0.html
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://apachetoday.com http://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: security
Posted by Gunther Birznieks <gu...@extropia.com>.
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 option
> >because of process persistance.
>
>I suspect this is why it is very easy to find hosting providers who
>provide PHP, and not as easy to find providers who support Embperl,
>Mason or other mod_perl solutions. Is there any effort to deal with
>this? (Per-virtual-server-process-sharing, with the option of
>dropping to zero processes, seems like a good start.) I'd really
>like to see languages like Embperl stand a better chance going
>head-to-head against PHP. It's very annoying to be able to whip
>together a great solution for my own servers, only to have to
>implement it for one of my clients in PHP, without nearly the power
>that Perl gives me.
>- --
>
>Kee Hinckley - Somewhere.Com, LLC - Cyberspace Architects
>Now Playing - Folk, Rock, odd stuff - http://www.somewhere.com/playlist.cgi
>
>I'm not sure which upsets me more: that people are so unwilling to accept
>responsibility for their own actions, or that they are so eager to regulate
>everyone else's.
>
>-----BEGIN PGP SIGNATURE-----
>Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
>
>iQA/AwUBOp4JiyZsPfdw+r2CEQJoRACgmZsE3GpeM2AhH2ooYID9iDxlnwAAmwf8
>+sZ0r0rmQNuahRV07TpZ761e
>=BSof
>-----END PGP SIGNATURE-----
__________________________________________________
Gunther Birznieks (gunther.birznieks@extropia.com)
eXtropia - The Web Technology Company
http://www.extropia.com/
Re: security
Posted by Todd Finney <tf...@boygenius.com>.
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
the same user as
> > the http process and removing other flags file access
(g-rwx). So nobody
> > besides the owner of the file (or the http process)
will be able to read
> > it.
>
> 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 understand that you want to store the SQL engine
authentication info,
> and users not to know each other's access credentials.
The only solution
> at this point is to either trust your users not to abuse
each other, or
> run a separate server for each one :(
There is a distinct possibility that I don't understand the
problem, but couldn't you set up a db connection sub in a
file, -750 customer.nobody, like this:
sub connect {
my $r = shift; # we need a request object from somewhere
return undef unless $r->server_name eq
'www.thisvirtualhost.org';
my $db_user = 'user';
my $db_pass = 'pass';
my $db_name = 'name';
use DBI;
my $dbh=DBI->connect(mumblemumblemumble);
return $dbh;
}
You might want to think about another way of doing your
connections, anyway. If you have lots of virtual hosts,
and all of them are opening distinct connections, you're
going to run out of MySQL handles pretty quick, or choke
your server with Apache::DBI cached handles. I've heard
that you can use a single connection module which then
changes to use a specified database, but I've never tried
that myself.
Todd
Re: security
Posted by Jimi Thompson <jt...@link.com>.
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, and
MySQL, but please don't quote me on that. Then again, we authenticate via
LDAP and some of our other parameters vary from what you have as well.
Thanks,
Stas Bekman wrote:
> 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 is that this scenario requires sensitive information inside
> > file. This means no problem when these users write their dymanic pages
> > inside a compiled program. I can chmod a-rw and nobody will be able to
> > take away user/password from a compiled program. The problem happens
> > when write their php or embperl pages!
> >
> > 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 the same user as
> > the http process and removing other flags file access (g-rwx). So nobody
> > besides the owner of the file (or the http process) will be able to read
> > it.
> >
> > since php have some security facilities, like: if the file owner id !=
> > the file the script is trying to open => fails.
> > My problem is with perl: how to solve such a problem in a perl
> > environment?
> > Does mod perl allows any kind of security, to prevent ones writing
> > script to read others files?
> >
> >
> > PS: All cgi runs through suexec, so even cgi are not able to run the
> > script, ok?
>
> 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 understand that you want to store the SQL engine authentication info,
> and users not to know each other's access credentials. The only solution
> at this point is to either trust your users not to abuse each other, or
> run a separate server for each one :(
>
> _____________________________________________________________________
> Stas Bekman JAm_pH -- Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide http://perl.apache.org/guide
> mailto:stas@stason.org http://apachetoday.com http://logilune.com/
> http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
--
Jimi Thompson
"It's the same thing we do every night, Pinky."
Re: security
Posted by Kee Hinckley <na...@somewhere.com>.
-----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 very easy to find hosting providers who
provide PHP, and not as easy to find providers who support Embperl,
Mason or other mod_perl solutions. Is there any effort to deal with
this? (Per-virtual-server-process-sharing, with the option of
dropping to zero processes, seems like a good start.) I'd really
like to see languages like Embperl stand a better chance going
head-to-head against PHP. It's very annoying to be able to whip
together a great solution for my own servers, only to have to
implement it for one of my clients in PHP, without nearly the power
that Perl gives me.
- --
Kee Hinckley - Somewhere.Com, LLC - Cyberspace Architects
Now Playing - Folk, Rock, odd stuff - http://www.somewhere.com/playlist.cgi
I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBOp4JiyZsPfdw+r2CEQJoRACgmZsE3GpeM2AhH2ooYID9iDxlnwAAmwf8
+sZ0r0rmQNuahRV07TpZ761e
=BSof
-----END PGP SIGNATURE-----