Re: lingerd mod_perl mod_ssl
Roger Espel Llima wrote: Vivek Khera wrote: mod_ssl alters the Apache API, so if you're doing the same then that's why they clash. Either that or you're patching something near what mod_ssl patches. Good guess. mod_ssl adds some initialization code add the end of common_init(), and so does lingerd which is why lingerd's patch wasn't applying cleanly. I had to make a different patch, for use with mod_ssl. The file is ftp://iagora.com/pub/software/lingerd/tmp/aplinger-ssl.diff (I'll put it in a proper lingerd release once I've checked a bit more closely how it all works) With this patch, I got Apache to build with lingerd, mod_perl and mod_ssl, and it seems to work fine. Netscape can access it, the ssl_engine_log doesn't show any errors, and keep-alive works. Awesome! I will give it a try once I get a chance, I've got some totally different things to deal with now... Btw, SSL really wants keep-alives on (key setup is slow), while mod_perl kind of wants them off (images should be served separately anyway, and lingerd is much more effective when keep-alives are off), so putting mod_ssl and mod_perl in the same Apache is a bit of a compromise. I'd still do it for secure dynamic pages, since you really need both, but I'd never serve non-secure (http) pages from the Apache that has mod_ssl in and keep-alives on. Interesting! On the server I have this set up on, I have apache running three different ports. Port 80 is just normal apache/mod_perl. Port 443 (https) is that plus mod_ssl. Port 80 and 443 just have normal web content, a bunch of plain ol' perl CGI's for administrating things, and some new Embperl scripts. Port 444 is my custom port. This is running mod_ssl. I'm trying to optimize that port for speed. All that's running is two mod_perl handlers. One of them takes care of validating a short list of registration keys, the other gives files (0-5mb in size) to the client after verifying that they are allowed. Pretty simple stuff, just some database calls and logging, and lots of error checking. The client on the other end is actually a Java application, which creates an SSL connection to my stuff. Apparently the classes the Java programmers are using don't support keep-alives. In our case I don't think it really matters, because after the initial quick auth request, the actual file downloads take quite a bit longer. At the moment I'm running lingerd with each port. Before I set up lingerd, they were having problems with the Java application hanging while downloading the files from the server. Now (even though apache will randomly segfault and die) everything on the client is working just fine. snip Let me know if something like that works for you... I want to officially support mod_ssl in the next release of lingerd, but I need more test data! I'll defenitly let you know how I make out once I get a chance to recompile everything, test it myself, and get our testers to test the Java app with it again. It works right now, but obviously it needs to be fixed properly. I'm hoping to do this stuff early next week... but with my luck it'll probably be later than that. Thanks for all your help people! It's much appreciated... this list rocks! -- Regards, Wim Kerkhoff, Software Engineer Merilus, Inc. -|- http://www.merilus.com Email: [EMAIL PROTECTED] S/MIME Cryptographic Signature
Re: security
-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-
Re: security
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 ([EMAIL PROTECTED]) eXtropia - The Web Technology Company http://www.extropia.com/
Re: security
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:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Passing control from one apache module to another
Hello, I am writing an apache perl module which logs HTTP environment variables. This is fine for static content (html, images) but is a problem for dynamic content such as php. I want my module to process the required HTTP variables and seamlessly pass the http request back to the control of other relevant apache modules. Something like chaning content handlers but where I can use other apache modules within the perl module (or at least pass control between them). Does anyone have an idea how to do this? If I figure it out I'll let the list know (presuming anybody is interested). = Mr. Michael Turley Gracious winner, Generous lover, All round great guy. __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
Re: Passing control from one apache module to another
On Thu, 1 Mar 2001, Michael Turley wrote: Hello, I am writing an apache perl module which logs HTTP environment variables. This is fine for static content (html, images) but is a problem for dynamic content such as php. I want my module to process the required HTTP variables and seamlessly pass the http request back to the control of other relevant apache modules. Something like chaning content handlers but where I can use other apache modules within the perl module (or at least pass control between them). Does anyone have an idea how to do this? If I figure it out I'll let the list know (presuming anybody is interested). Provided you do this in a mod_perl handler before mod_mime is called (i.e. before the type handler phase), then it should just work. I suggest doing it in a Trans (uri translate) handler, and return DECLINED. -- Matt/ /||** Founder and CTO ** ** http://axkit.com/ ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\
Re: lingerd mod_perl apache_ssl
Vivek Khera wrote: mod_ssl alters the Apache API, so if you're doing the same then that's why they clash. Either that or you're patching something near what mod_ssl patches. Using apache_ssl requires no alteration of the current lingerd. Built it last night and am currently testing. apache-1.3.14 + apache_ssl-1.4.2 + modperl-1.24_01 [EMAIL PROTECTED]
Re: Passing control from one apache module to another
I am writing an apache perl module which logs HTTP environment variables. This is fine for static content (html, images) but is a problem for dynamic content such as php. Why doesn't Log Format work for you? - Perrin
Re: apache question...
RedirectMatch ^/index.html http://new.server.com/index.html Rob At 8:33 PM -0700 2/28/01, Joseph Crotty wrote: I am set up on apache_1.3.14/mod_perl currently, however, have an older non-mod_perl apache_1.3.6. The old apache's index.html needs to redirect to the index.html on the new apache/mod_perl. The old and new apache servers are on different unix boxes. Anyone think of an elegant block directive solution, because I can't. Thanks, Joe Crotty -- "Only two things are infinite: The universe, and human stupidity. And I'm not sure about the former." --Albert Einstein
HTML Mason 1.0 setup
I've been using HTML::Mason under mod_perl on my site for awhile, using
0.89, and I like it lots. :-) So when the new 1.0 came out, I went to go
upgrade, and broke EVERYTHING.
Not only that, but, I haven't been able to make sense out of what Mason
wants for its dir heirarchy, anyway:
First, comp_root (apparently) needs to be the same as DocumentRoot, which
seems horribly insecure... if I could find another way to do it, I would,
but for now, knowing the path my components run under makes them viewable
_AS SOURCE_ by anyone who knows the url.
and in the same vein, the *ONLY* way I could get it to run was to put it's
data_dir under DocumentRoot as well.
Why can't I have
/home/httpd/html
/home/httpd/components (instead of /home/httpd/html/components)
/home/httpd/mason (instead of /home/httpd/html/mason)
? Or more correctly, how do I tell Mason to use that kind of strucure?
And what (the docs don't say, the changelog isn't indicative) changed in the
required setup procedure at 1.0? My friend called me wanting to do
HTML::Mason, which I told him was absolutely awesome for development, but he
couldn't get it running at all (he only had access to the 1.0 from CPAN)
(and we only had my working config to start with).
This is the relevant section of my startup.pl:
=
package HTML::Mason;
use strict;
use Apache::Constants qw(:common);
use Date::Format;
local $| = 1;
my $parser = new HTML::Mason::Parser;
my $interp = new HTML::Mason::Interp ( parser = $parser,
comp_root = '/home/httpd/html',
data_dir =
'/home/httpd/html/mason', );
my $ah = new HTML::Mason::ApacheHandler ( interp = $interp,
output_mode = 'batch',
# output_mode = 'stream',
error_mode = 'html', # fatal
debug_mode = 'all',
debug_perl_binary =
'/usr/bin/perl',
debug_handler_script =
'/etc/httpd/lib/perl/startup.pl',
debug_handler_proc =
'HTML::Mason::handler', );
# {{{ setuid/taint shut UP!
if (0) {
my @test = ( qw/1 2 3/ );
my @files_written = map {/(.*)/; $1} @test # $interp-files_written
;
warn "Trying to deal w/ tainting: ",
Data::Dumper-Dump([ \@files_written ], [ qw/files_written/ ] ) ,
"\n";
chown( [getpwnam('nobody')]-[2],[getpwnam('nobody')]-[2],
@files_written );
}
# }}}
sub handler {
my ($r) = @_;
$ah-handle_request($r);
}
# {{{ globals
{
package HTML::Mason::Commands;
use vars qw($dbh %session);
# my ($dsn, $user, $pass) = (My::dbi_connect_string(),
My::dbi_pwd_fetch());
# $dsn = 'dbi:Proxy:hostname=devel;port=;dsn=' . $dsn;
{
local $^W = 1;
# ( dsn, username, password )
# $interp-set_global(dbh = DBI-connect(My::dbi_connect_string(),
My::dbi_pwd_fetch()));
#$dbh = DBI-connect(My::dbi_connect_string(),
My::dbi_pwd_fetch()) or die DBI-errstr;
#$dbh-{AutoCommit} = 0;
}
}
# }}} globals
=
TIA
L8r,
Rob
#!/usr/bin/perl -w
use Disclaimer qw/:standard/;
Re: HTML Mason 1.0 setup
At 11:03 AM -0800 3/1/01, Rob Bloodgood wrote: I've been using HTML::Mason under mod_perl on my site for awhile, using 0.89, and I like it lots. :-) So when the new 1.0 came out, I went to go upgrade, and broke EVERYTHING. Not only that, but, I haven't been able to make sense out of what Mason wants for its dir heirarchy, anyway: First, comp_root (apparently) needs to be the same as DocumentRoot, which seems horribly insecure... if I could find another way to do it, I would, but for now, knowing the path my components run under makes them viewable _AS SOURCE_ by anyone who knows the url. Well, the only reason a component should be visible as source is if Mason isn't working, right? So saying that it's horribly insecure is the same as saying that it's not working right? Here's what I use in my httpd.conf to get get Mason to handle all files with .md extensions (Mason documents). These are the top level components that return an entire page. The .mc files are other components which in the comp_root and thus available be called by other Mason components, but cannot be requested directly via a URL. This seems secure to me and it's been working just fine from 0.7 or so up through 1.0. AddType text/html .md FilesMatch ".*\.md$" SetHandler perl-script PerlHandler HTML::Mason Options Indexes FollowSymLinks ExecCGI /FilesMatch FilesMatch ".*\.mc$" Order allow,deny Deny from all /FilesMatch and in the same vein, the *ONLY* way I could get it to run was to put it's data_dir under DocumentRoot as well. Is it a file permissions problem? If you're running your webserver as user 'nobody', nobody has to have write access to the data_dir. You definitely don't want to have your data_dir under your DocumentRoot. Ray
Re: Passing control from one apache module to another
You mean in httpd.conf? I could use that but what I hoped to do was pull http vars into a database for each server request. This is so someone could interactively view accesses rather than reviewing static pregenerated files. The overhead of opening and closing readonly filehandles on different files which apache writes to and then processing that data seems a little messier than a simple sql insert. I'm reading the apache modules book by L Stein and D MacEachern to get a better understanding apache internals. --- Perrin Harkins [EMAIL PROTECTED] wrote: I am writing an apache perl module which logs HTTP environment variables. This is fine for static content (html, images) but is a problem for dynamic content such as php. Why doesn't Log Format work for you? - Perrin = Mr. Michael Turley Gracious winner, Generous lover, All round great guy. __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
Re: HTML Mason 1.0 setup
Hi Rob
I just went through this exact situation this morning. I ended up
(unnecessarily) recompiling apache/mod_perl in the hopes of fixing it. All
that really needed to be done was to add "use HTML::Mason::ApacheHandler;"
to mason's handler.pl. I'm assuming your v0.89 site was working properly.
Anyway, my apache and mod_perl are up to date now at least.
Bill
At 11:03 AM -0800 3/1/01, Rob Bloodgood wrote:
I've been using HTML::Mason under mod_perl on my site for awhile, using
0.89, and I like it lots. :-) So when the new 1.0 came out, I went to go
upgrade, and broke EVERYTHING.
Not only that, but, I haven't been able to make sense out of what Mason
wants for its dir heirarchy, anyway:
First, comp_root (apparently) needs to be the same as DocumentRoot, which
seems horribly insecure... if I could find another way to do it, I would,
but for now, knowing the path my components run under makes them viewable
_AS SOURCE_ by anyone who knows the url.
and in the same vein, the *ONLY* way I could get it to run was to put it's
data_dir under DocumentRoot as well.
Why can't I have
/home/httpd/html
/home/httpd/components (instead of /home/httpd/html/components)
/home/httpd/mason (instead of /home/httpd/html/mason)
? Or more correctly, how do I tell Mason to use that kind of strucure?
And what (the docs don't say, the changelog isn't indicative) changed in the
required setup procedure at 1.0? My friend called me wanting to do
HTML::Mason, which I told him was absolutely awesome for development, but he
couldn't get it running at all (he only had access to the 1.0 from CPAN)
(and we only had my working config to start with).
This is the relevant section of my startup.pl:
=
package HTML::Mason;
use strict;
use Apache::Constants qw(:common);
use Date::Format;
local $| = 1;
my $parser = new HTML::Mason::Parser;
my $interp = new HTML::Mason::Interp ( parser = $parser,
comp_root = '/home/httpd/html',
data_dir =
'/home/httpd/html/mason', );
my $ah = new HTML::Mason::ApacheHandler ( interp = $interp,
output_mode = 'batch',
# output_mode = 'stream',
error_mode = 'html', # fatal
debug_mode = 'all',
debug_perl_binary =
'/usr/bin/perl',
debug_handler_script =
'/etc/httpd/lib/perl/startup.pl',
debug_handler_proc =
'HTML::Mason::handler', );
# {{{ setuid/taint shut UP!
if (0) {
my @test = ( qw/1 2 3/ );
my @files_written = map {/(.*)/; $1} @test # $interp-files_written
;
warn "Trying to deal w/ tainting: ",
Data::Dumper-Dump([ \@files_written ], [ qw/files_written/ ] ) ,
"\n";
chown( [getpwnam('nobody')]-[2],[getpwnam('nobody')]-[2],
@files_written );
}
# }}}
sub handler {
my ($r) = @_;
$ah-handle_request($r);
}
# {{{ globals
{
package HTML::Mason::Commands;
use vars qw($dbh %session);
# my ($dsn, $user, $pass) = (My::dbi_connect_string(),
My::dbi_pwd_fetch());
# $dsn = 'dbi:Proxy:hostname=devel;port=;dsn=' . $dsn;
{
local $^W = 1;
# ( dsn, username, password )
# $interp-set_global(dbh = DBI-connect(My::dbi_connect_string(),
My::dbi_pwd_fetch()));
#$dbh = DBI-connect(My::dbi_connect_string(),
My::dbi_pwd_fetch()) or die DBI-errstr;
#$dbh-{AutoCommit} = 0;
}
}
# }}} globals
=
TIA
L8r,
Rob
#!/usr/bin/perl -w
use Disclaimer qw/:standard/;
Re: security
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:[EMAIL PROTECTED] 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."
Using Apache::Sandwich on php files
Hi I'm trying to figure out how to "Sandwich" php files. Is this possible? For my .htm* files I have: FilesMatch "\.html|htm$" SetHandler perl-script PerlHandler Apache::Sandwich PerlSetVar HEADER "/includes/head.html" PerlSetVar SandwichHandler server_parsed /FilesMatch What would I need to change to have this work for php? Thanks -- Clint Gilders Servermaster Onlinehobbyist Inc. [EMAIL PROTECTED]
mod_php mod_perl install with apache problems - same story :(
Hello! Well, I have seen a ton of people with this problem but no answers. I have mod_php compiled in with apache along with mod_ssl. I want to use apxs to build mod_perl. I have done this and apache starts fine, but it does not render the perl, for lack of better terms. It simply prints the source. The only directives i have in httpd.conf are LoadModule and DirectoryIndex. When I start apache, apachectl startssl, the eror log says: Apache/1.3.17 (Unix) mod_perl/1.25 PHP/4.04 mod_ssl/2.8.0 OpenSSL/0.9.6 configured -- resuming normal operations. This all looks fine. Anyone have any insight as to what my problem may be? Thank you! -- Terry Davis Systems Administrator BirdDog Solutions, Inc. 2102 N 117th Ave Omaha, NE 68164 voice: (402) 829-6059 fax: (402) 829-6199 pager: (877) 973-6995 [EMAIL PROTECTED] www.birddog.com
Re: HTML Mason 1.0 setup
"Ray" == Ray Zimmerman [EMAIL PROTECTED] writes: Ray At 11:03 AM -0800 3/1/01, Rob Bloodgood wrote: and in the same vein, the *ONLY* way I could get it to run was to put it's data_dir under DocumentRoot as well. Ray Is it a file permissions problem? If you're running your webserver as Ray user 'nobody', nobody has to have write access to the data_dir. You Ray definitely don't want to have your data_dir under your DocumentRoot. Nobody and nogroup should not have writes anywhere. Your web server thus should not run as "nobody", but as a special user. On Debian GNU/Linux systems, the web server runs as "www-data", group "www-data". -- mailto: (Karl M. Hegbloom) [EMAIL PROTECTED] http://www.microsharp.com phone://USA/WA/360-260-2066
Re: mod_php mod_perl install with apache problems - same story :(
This is probably what you need more or less. You have to tell Apache what files are your mod perl scripts (or more specifically what files you want handled by Apache::Registry - the persistent cgi program module). Alias /perl/ /home/httpd/perl/ PerlModule Apache::Registry Location /perl SetHandler perl-script PerlHandler Apache::Registry Options ExecCGI allow from all PerlSendHeader On /Location http://perl.apache.org/guide/config.html is the configuration portion of a great guide by Stas Berkman that has this information in it. The O'Reilly book Building Apache Modules with Perl and C has some instructions about this as well. Recommened. Wade - Original Message - From: "Terry Davis" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, March 01, 2001 12:53 PM Subject: mod_php mod_perl install with apache problems - same story :( Hello! Well, I have seen a ton of people with this problem but no answers. I have mod_php compiled in with apache along with mod_ssl. I want to use apxs to build mod_perl. I have done this and apache starts fine, but it does not render the perl, for lack of better terms. It simply prints the source. The only directives i have in httpd.conf are LoadModule and DirectoryIndex. When I start apache, apachectl startssl, the eror log says: Apache/1.3.17 (Unix) mod_perl/1.25 PHP/4.04 mod_ssl/2.8.0 OpenSSL/0.9.6 configured -- resuming normal operations. This all looks fine. Anyone have any insight as to what my problem may be? Thank you! -- Terry Davis Systems Administrator BirdDog Solutions, Inc. 2102 N 117th Ave Omaha, NE 68164 voice: (402) 829-6059 fax: (402) 829-6199 pager: (877) 973-6995 [EMAIL PROTECTED] www.birddog.com
security!
After some time playing with modperl, i realized some problem (that's the way i call them) related with modperl! By looking the way modperl works today, it's clearly it were not desgined to SECURELY support a multi-user environment. For instance: Any user can write a script that will be able to read any file owned by the httpd server, in a multi-user environment it should not be allowed. A gentle way to prevent this would be not to allow a script read a file whose owner id is not the same from the script owner id, isn't it? Another problem: process creation should be wrapped by apache suexec mechanism, is it currently done this way? Why not? May some here confirm me that if i am a security concious admin, i should not make modperl+embperl available to my user?
Re: security!
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 time playing with modperl, i realized some problem (that's the way i call them) related with modperl! By looking the way modperl works today, it's clearly it were not desgined to SECURELY support a multi-user environment. For instance: Any user can write a script that will be able to read any file owned by the httpd server, in a multi-user environment it should not be allowed. A gentle way to prevent this would be not to allow a script read a file whose owner id is not the same from the script owner id, isn't it? Another problem: process creation should be wrapped by apache suexec mechanism, is it currently done this way? Why not? May some here confirm me that if i am a security concious admin, i should not make modperl+embperl available to my user? -- Best Regards Vladimir Ivaschenko RedHat Certified Linux Engineer (RHCE)
Re: security!
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 development weve been using it in house for 3 months its so nice multiple developers on one box!!
CONNECT proxy rewrite
Does anybody know how to alter the destination of a CONNECT transaction
(in this case "secure proxy" request) in mod_perl?
$r-uri("newplace:newport") in a Trans handler doesn't seem to do it.
Re: security
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: [OT] security!
Hello, GRBy looking the way modperl works today, it's clearly it were not GRdesgined to SECURELY support a multi-user environment. For instance: Any GRuser can write a script that will be able to read any file owned by the GRhttpd server, in a multi-user environment it should not be allowed. This is a general Unix webserver issue and not specific to mod_perl, so I've marked your message [OT] for off-topic. You cannot easily avoid this problem in general. (1) HTTP requests can come from anybody. (2) All HTTP requests are serviced by the same webserver. (3) The webserver needs to be able to read and execute scripts. Therefore, in general if untrusted users can write webserver executed scripts, they can read anything the webserver can. GRA gentle way to prevent this would be not to allow a script read a file GRwhose owner id is not the same from the script owner id, isn't it? This is fine, but you're talking about revamping Unix permissions here, not at the webserver level. The webserver cannot enforce this condition because the webserver only runs the script, it is not the OS that the script runs on. GRAnother problem: process creation should be wrapped by apache suexec GRmechanism, is it currently done this way? Why not? This could help sidestep the issue. It is not done this way by default, because even using suexec doesn't automatically make your scripts secure, and in fact it can make the situation worse. GRMay some here confirm me that if i am a security concious admin, i GRshould not make modperl+embperl available to my user? If you are a security conscious admin, and you cannot trust your users, you should not make mod_perl available to them. In fact you should not make any dynamic HTTP functionality available to them--CGI, ISAPI, FastCGI, or anything else. Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 --
RE: security!
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 executable programs as a particular user. AFAIK you can't impersonate a user on unixy environments without forking a new process. And forking a new process under mod_perl really defeats the purpose. Plus, because it is easy to crash or stall a server running mod_perl, each mod_perl user really needs administrative access to his or her own web server, including the ability to stop and start it. One method (as people have noted) is to create a number of complete virtual chrooted unix environments, each with its own webserver. Another is to have pools of httpds: each pool running as a different user and listening to a unique port; then you run a proxying front-end to direct traffic to each user's server based on hostname or whatever. Complicated, and (I believe) quite memory-intensive. More info is in the guide: http://perl.apache.org/guide/multiuser.html#ISPs_providing_mod_perl_services In mod_perl 2.0 (when it is released) you will have the opportunity (depending on your platform) to use the hybrid process/threading model. Then you will have a single httpd for each user, and that httpd will be able to handle multiple requests via multiple threads. This solution could probably be used in an ISP, to achieve the same level of user-partitioning that is now availble under CGI via suexec. Michael
RE: security!
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 question. With CGI, you use the suexec mechanism to start executable programs as a particular user. AFAIK you can't impersonate a user on unixy environments without forking a new process. And forking a new process under mod_perl really defeats the purpose. Does it? 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, notes/pnotes, etc. I realise a lot of this would be tricky and would require RPC (thus opening up a security hole in its own right) but I think it would be worthwhile. I certainly don't like the way we're all assuming mod_perl 2.0 is going to solve all our problems. It won't. It will just give us some fresh ones (like making all modules thread safe). -- Matt/ /||** Founder and CTO ** ** http://axkit.com/ ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\
(changing userids/2.0/suexec) was: RE: security!
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 executable programs as a particular user. AFAIK you can't impersonate a user on unixy environments without forking a new process. And forking a new process under mod_perl really defeats the purpose. changing userids has nothing to do with fork()... the problem is simply that it requires root priviledges, and since you need to give them up permanently if you're going to run some else's "insecure" code, that usually means a temporary process... (which typically means fork()ing a short lived process, so you could make the connection)... The apache 2.0 model seems to include a mechanism for routing requests to a group of apache child processes which have _already_ switched to the target userid... in short, the pre-fork model is extended to have classes of pre-forked processes... it seems to be a mightly good fix for this particular problem. That said, I only took about two minutes reading one of the URLs posted earlier today, but I got that far and said "that'll work!" and quit reading until I have time to actually test some of this ... -Tom
RE: HTML Mason 1.0 setup
Hi Rob,
I've been using HTML::Mason under mod_perl on my site for
awhile, using
0.89, and I like it lots. :-) So when the new 1.0 came out,
Me too 8^) I'm a Mason junkie for going on 4 years now I think - since 0.4
8^)
I went to go
upgrade, and broke EVERYTHING.
There are some very specific differences. Make sure that you are setting up
the ApacheHandler correctly - you may need to compare the handler included
in the distribution. Most importantly make sure you have
use HTML::Mason::ApacheHandler;
I did not see this in your sample attachment.
Not only that, but, I haven't been able to make sense out of
what Mason
wants for its dir heirarchy, anyway:
First, comp_root (apparently) needs to be the same as
DocumentRoot, which
seems horribly insecure... if I could find another way to do
it, I would,
This is not correct - I use a drastically different component root than my
document root on all of my installations, specifically for security reasons.
Make sure you un-comment the lines in the handler.pl for:
chown ( scalar(getpwnam "nobody"), scalar(getgrnam "nobody"),
$interp-files_written );
Substitute the "nobody" for the user group your web server runs under. The
transient files created by Mason will need to be writable by that user, and
the Mason handler will take care of the permissions issues for you.
Why can't I have
/home/httpd/html
/home/httpd/components(instead of /home/httpd/html/components)
/home/httpd/mason (instead of /home/httpd/html/mason)
I would generally use a directory structure like:
AppName/web/pub/ (document root, public HTML documents and top-level Mason
components)
AppName/web/elements/ (non top-level Mason components)
And then set the component root to AppName/web, allowing you to use absolute
references in your and $m-comp calls such as
$m-comp("/elements/banner.html"), or /elements/footer.html
This ensures that banner.html and footer.html are NOT accessible directly
via the web server.
My Mason Interpreter object is usually set up like:
my $interp = new HTML::Mason::Interp (parser=$parser,
allow_recursive_autohandlers=undef,
comp_root='/home/www/AppName/web',
data_dir='/var/masondata');
Then my VirtualHost directive sets:
DocumentRoot /home/www/AppName/pub
Check out that use directive I noted at the top - it might be your sticking
point.
Good Luck!
Steve
RE: security!
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 similar to CGI but providing the full Apache API, including logging, notes/pnotes, etc. How would it be similar to CGI then? I'm guessing you want to be able to register a separate program to handle any part of the request phase? I certainly don't like the way we're all assuming mod_perl 2.0 is going to solve all our problems. It won't. Well, personally, I use my own servers when I use mod_perl, so this particular problem doesn't affect me. But I think that finding a good ISP-friendly mod_perl solution would be good in general to help promote Perl as a viable modern web programming language. I think that promoting perl as a *modern* web programming language would be good for the perl community because it would encourage more people to use modern programming practices (strict mode, OO etc.) rather than the quick one-offs of yore that were so popular with CGI. Not that there's anything wrong with that of course. I know some people who run a small ISP and they would probably consider offering a mod_perl service, if they could put a bunch of users on a box and protect the users from each other reasonably well. Of course, mod_perl is not the only way to promote Perl on the web, but this is a mod_perl list :) Michael
Tip : building Apache modules under Compaq Tru-64 Unix (formerly Digital Unix / OSF1)
Guys,
Those of us with Tru-64 often run into some interesting problems
when buiilding Open Source software, particularly software which does not
come with a configure script. The recent upgrade to v5.0 of Tru-64 caught
out a lot of the configure scripts, but this tip is for those who have to
'wing it' completely.
Current Apache releases contain the facility to build your httpd
executable with support for dynamically linked modules (DSO). This means
that your httpd executable no longer gets bigger with each successive module
added to it. This is accomplished via the 'apxs' tool.
PyApache is a module designed to speed up the execution of Python
CGI scripts running under the Apache webserver. It comes with a single
README containing a line which shows you how the suggested APXS command.
Because of the nature of the Tru-64 compilation/linking environment, the
supplied script will *not* work properly.
To build PyApache under Tru-64, save this in a script called
'apxs.sh' or similar :
#!/bin/ksh
PYTHON="/usr/local/python-1.5.2"
PYVER="python1.5"
PYTHONLIB=$PYTHON/lib/$PYVER
PYINC=${PYTHON}/include
APACHEBIN=/usr/local/pyapache/bin
echo "Building ${MODULE}"
$APACHEBIN/apxs \
-c \
-Wl,"-shared -expect_unresolved '*'" \#
essential for Tru-64
-I${PYINC} \
-L${PYTHONLIB} \
-L${PYTHONLIB}/config \
-lpython1.5 \
-lm \
-lpthread \
${MODULE}.c
if [ $? -eq 0 ]; then
echo "Installing ${MODULE}"
$APACHEBIN/apxs \
-i \
-a \
${MODULE}.so
fi
The net payoff for this effort was an increase from 15
requests/second to over 58 requests/sec on our Alpha. Definitely worth it !
Note that the script above should work for most Apache modules which support
DSO - you'll just need to change the include and library paths. Other
options such as threading may or may not suit your environment. Your version
of Python may differ, and so may the location of your Apache executables.
Some installs have apxs in apache/sbin instead of apache/bin, but thats
purely personal choice. If the build works, you should see apxs output
indicating that httpd.conf is being updated. Please consult the apxs manpage
(under apache/man) for further details re the options you need to pass apxs.
The above script uses Korn shell syntax - it may need to be modified if you
prefer another shell. Don't forget to read the INSTALL and README files to
ensure that all necessary configuration is done before restarting Apache.
Finally, my apologies for the size of this post !
Regards,
Arthur
Arthur Watts
Software Engineer GBST Automation
Global Banking Securities Transactions
Telephone + 61 7 3331
mailto: [EMAIL PROTECTED]
www.gbst.com
PerlModule vs use in a Perl section
I was using Apache::Status to learn a bit about what is loaded by my server, and I am wondering about a detail... If I put this: Perl use Apache::Foo; /Perl Or this: PerlModule Apache::Foo I would expect the two to behave the same, but they don't! The "use" in the Perl section does as I was expecting (the module and everything it loaded was right there), but while the PerlModule seemed to change something (Apache::Util was loaded, which I use in my Apache::Foo module), Apache::Foo itself wasn't on the list of loaded modules! Using a "+" when installing the PerlHandler (like this: "PerlHandler +Apache::Foo") did load the module as expected. Now, why aren't modules loaded with PerlModule not showing up in the loaded modules list of Apache::Status? Thanks! -- Pierre Phaneuf http://www3.sympatico.ca/pphaneuf/
