modperl security model question
Thanks again for the help - I have another one- My application consists of perl modules with file permissions set only to a particular user 'burkhold'. The database password is kept in plaintext in one of those modules. I use the User: and Group: directives in access.conf to cause the uid of the spawned httpd process to have permission to execute the code. It works fine, except that it seems I can't embed 'User: burkhold' inside a Location directive, so all requests have to be served as 'burkhold'. It seems like there should be some simple way in apache to specify what user the httpd should be set to when it's spawned, but except for the global User: I haven't found a way. If I can't make this work, I may have to turf module handlers and go with a Registry and setuid solution, which I think would be a shame since I think handlers are a lot more elegant. This is probably well-trodden territory - anyone got a solution? Thanks again, several of you have been helpful to me, and I do appreciate it. Happy Easter. //Thomas Thomas K. Burkholder [EMAIL PROTECTED]
Re: modperl security model question
On Sun, 15 Apr 2001, Thomas K. Burkholder wrote: Thanks again for the help - I have another one- My application consists of perl modules with file permissions set only to a particular user 'burkhold'. The database password is kept in plaintext in one of those modules. I use the User: and Group: directives in access.conf to cause the uid of the spawned httpd process to have permission to execute the code. It works fine, except that it seems I can't embed 'User: burkhold' inside a Location directive, so all requests have to be served as 'burkhold'. It seems like there should be some simple way in apache to specify what user the httpd should be set to when it's spawned, but except for the global User: I haven't found a way. An httpd process is spawned to handle _all_ locations, that is why the Group/User can only be specified per server. If apache was able to spawn separate processes to only handle one location, your suggestion would work. The only solution i would offer would be to proxy all requests to that location to another apache server, running on a different port, as user bukhold. The main server could then run with whatever user is appropriate, and have a ProxyPass directive to forward requests requiring user burkhold. sterling If I can't make this work, I may have to turf module handlers and go with a Registry and setuid solution, which I think would be a shame since I think handlers are a lot more elegant. This is probably well-trodden territory - anyone got a solution? Thanks again, several of you have been helpful to me, and I do appreciate it. Happy Easter. //Thomas Thomas K. Burkholder [EMAIL PROTECTED]
Build problem (lperl)
I'm trying to have mod_perl build apache during its own build, but I'm getting an error that I can't dig any answers up on. I have the libperl.so.5.6.0 in /usr/lib, but I'm uncertain how to get compiler to recognize that it is there. I ran ldconfig, but still no luck. Here's the command I'm using (I'm trying to use Slashcode, and they have this in their directions): perl Makefile.PL APACHE_SRC=../apache_1.3.19 DO_HTTPD=1\ USE_APACI=1 PERL_MARK_WHERE=1 EVERYTHING=1 \ APACHE_PREFIX=/usr/local/apache And here's the output: Will configure via APACI cp apaci/Makefile.libdir ../apache_1.3.19/src/modules/perl/Makefile.libdir cp apaci/Makefile.tmpl ../apache_1.3.19/src/modules/perl/Makefile.tmpl cp apaci/README ../apache_1.3.19/src/modules/perl/README cp apaci/configure ../apache_1.3.19/src/modules/perl/configure cp apaci/libperl.module ../apache_1.3.19/src/modules/perl/libperl.module cp apaci/mod_perl.config.sh ./apache_1.3.19/src/modules/perl/mod_perl.config.sh cp apaci/load_modules.pl.PL ./apache_1.3.19/src/modules/perl/load_modules.pl.PL cp apaci/find_source.PL ../apache_1.3.19/src/modules/perl/find_source.PL cp apaci/apxs_cflags.PL ../apache_1.3.19/src/modules/perl/apxs_cflags.PL cp apaci/mod_perl.exp ../apache_1.3.19/src/modules/perl/mod_perl.exp PerlDispatchHandler.enabled PerlChildInitHandlerenabled PerlChildExitHandlerenabled PerlPostReadRequestHandler..enabled PerlTransHandlerenabled PerlHeaderParserHandler.enabled PerlAccessHandler...enabled PerlAuthenHandler...enabled PerlAuthzHandlerenabled PerlTypeHandler.enabled PerlFixupHandlerenabled PerlHandler.enabled PerlLogHandler..enabled PerlInitHandler.enabled PerlCleanupHandler..enabled PerlRestartHandler..enabled PerlStackedHandlers.enabled PerlMethodHandlers..enabled PerlDirectiveHandlers...enabled PerlTableApienabled PerlLogApi..enabled PerlUriApi..enabled PerlUtilApi.enabled PerlFileApi.enabled PerlConnectionApi...enabled PerlServerApi...enabled PerlSectionsenabled PerlSSI.enabled PERL_MARK_WHERE.enabled (experimental) Will run tests as User: 'nobody' Group: 'root' (cd ../apache_1.3.19 CC="cc" CFLAGS=" -DPERL_MARK_WHERE=1 -DDEBIAN -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64" ./configure --activate-module=src/modules/perl/libperl.a --disable-rule=EXPAT --prefix=/usr/local/apache) Configuring for Apache, Version 1.3.19 + using installation path layout: Apache (config.layout) + activated perl module (modules/perl/libperl.a) Creating Makefile Creating Configuration.apaci in src + id: mod_perl/1.25 + id: Perl/v5.6.0 (linux) [perl] cd ..; cc -DLINUX=22 -DMOD_PERL -DUSE_PERL_SSI -DDEBIAN -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DUSE_HSREGEX -DNO_DL_NEEDED -DPERL_MARK_WHERE=1 -DDEBIAN -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 `./apaci` -I. -I/usr/lib/perl/5.6.0/CORE-o helpers/dummy helpers/dummy.c -lm -lcrypt -rdynamic -L/usr/local/lib /usr/lib/perl/5.6.0/auto/DynaLoader/DynaLoader.a -L/usr/lib/perl/5.6.0/CORE -lperl -lnsl -ldl -lm -lc -lcrypt /usr/bin/ld: cannot find -lperl collect2: ld returned 1 exit status make: *** [dummy] Error 1 Thanks in advance, -- Sean LeBlanc - [EMAIL PROTECTED] A programmer is someone who solves a problem you didn't know you had in a way you don't understand.
Re: is Apache::Request upload-fh lazy or not?
"Thomas K. Burkholder" [EMAIL PROTECTED] writes:
Hi again,
Thanks to those who helped me with the install issue. I've mostly
resolved that, and now have a new question that seems much more
mod-perl-ish:
I have code that does essentially this:
sub handler {
my $r = shift;
$r = Apache::Request-new($r);
my $handle = $r-upload('filename');
my $fh = $handle-fh;
...
}
I'd like to write upload code that shows progress (via a fork and
refresh header trick - don't worry about that). What I'm wondering is,
by the time I get $fh above (or even by the time I'm in the handler for
all I know) do I already have the entire file uploaded, or is it done
lazily as reads are performed on $fh? I'm not very good at reading this
XS stuff, but I looked at libapreq and from that I suspect it's all done
up front. Is there any way to read it incrementally?
Has anyone solved this problem before? I want to provide an upload
function for my web app that shows the user periodic progress or maybe
even allows them to cancel it part way through. Is this too much of a
reach for http/mod_perl?
I've managed to do this in the past by modifying mod_proxy on the
front-end server, but I think the ability to do this from within
Apache::Request would be a nice feature. Recently David Prosa added
an upload hook to the C API for libapreq, and yesterday I put together
a patch to Request.xs that provides a Perl interface.
It would work something like this:
my $hook = sub {
my ($upload, $buf, $len, $data) = @_;
my $fh = $upload-fh;
print $fh $buf;
warn "HOOK_DATA = $data: wrote $len bytes for " . $upload-name;
}
my $apr = Apache::Request-new( Apache-request,
HOOK_DATA = "Some parameters",
UPLOAD_HOOK = $hook,
);
my $parm_table = $apr-param; # causes upload parsing to begin
my $upload = $apr-upload('file');
my $fh = $upload-fh;
...
In this case, $hook will be called in place of the normal internal
(buffered) writes to a temp file. Note that $upload-fh now
must auto-vivify a temp file if none was created by libapreq itself.
That's probably a feature, but it may require some care if the hook sub
is poorly designed. $upload-size will now count the size of the data
sent by the browser, which may or may not be the same as the size of
the temp file (depending on what the hook does with it). Otherwise
upload objects should behave normally ($upload-fh still dup's and
seek's outside of the hook sub).
I'll post the diff to the apreq-dev list after I've tested it a bit
more. Also, please contact me or follow up to the list if anyone has
some comments/suggestions for improving the API before committing it to
CVS.
Thanks.
--
Joe Schaefer
Re: is Apache::Request upload-fh lazy or not?
Joe Schaefer [EMAIL PROTECTED] writes: Apache::Request would be a nice feature. Recently David Prosa added ^^^ Ugh- he's David *Welton*, and he's using libapreq in his mod_dtcl module. Damn, that's twice I've done that to him - I'm very, very sorry, David :( -- Joe Schaefer
mac_check in eagle book
I was wondering if someone could explain to me why in the eagle book it is necessary to perform an md5 twice before sending a mac_check to a user of a number of fields. I read in the mod_perl book that this is done 'to prevent technically savy users from appending data to the @fields'. my $mac_check = md5_hex($secret, md5_hex(join '', $secret, @fields)); What I am wondering is, what situation would a user be able to append data to the fields? I believe if you change only one bit of the data, the mac will change, so I am a little confused. thanks, --eric
Apache growing.
Hey all, Have a slight problem with my mod_perl script, Every time i run it i notice that apache grows in size. The increase in size is about 10 kb per 100 executions, but if this carries on i cant put the script on in a production environment. Can someone help me figure why this is happening ? Will mention that I am using DBI in the script to connect to a MySQL server. Thought that perhaps it is happening because of the multipler connect requests But i have Apache::DBI on the server so that should take of the connect statements i think I am new to mod_perl so perhaps i am missing something here. I ran my script with Apache::Leak and that left me a clean error_log file so i am at a loose end, would appreciate any help .. Thanks Aquitaine
Re: Apache growing.
On Mon, Apr 16, 2001 at 04:44:23AM +0530, [Aquitaine] wrote: Have a slight problem with my mod_perl script, Every time i run it i notice that apache grows in size. The increase in size is about 10 kb per 100 executions, but if this carries on i cant put the script on in a production environment. Can someone help me figure why this is happening ? Will mention that I am using DBI in the script to connect to a MySQL server. We have the same problem. I believe my code is squeaky clean but each Apache process's unique pages count increases with time. Still, 10kb/100req isn't all that bad. Make use of MaxRequestsPerChild. At a rate of 500, you will still win on the reduced overhead and not have Apache processes that grow out of control. I scoffed at the idea when I first heard it, but was much happier to consider it after I reached my wits end. It works nicely with that variable set, so I'll leave it at that. (I'm not sure this is even a code problem. Maybe perl is just bad at keeping a single consistent working set and the copy-on write from the parent Apache kicks in and keeps increasing unique per process memory consumption). -- Michael Bacarella [EMAIL PROTECTED] Technical Staff / System Development, New York Connect.Net, Ltd.
mac_check in eagle book
I was wondering if someone could explain to me why in the eagle book it is necessary to perform an md5 twice before sending a mac_check to a user of a number of fields. I read in the mod_perl book that this is done 'to prevent technically savy users from appending data to the @fields'. my $mac_check = md5_hex($secret, md5_hex(join '', $secret, @fields)); What I am wondering is, what situation would a user be able to append data to the fields? I believe if you change only one bit of the data, the mac will change, so I am a little confused. thanks, --eric
Re: mac_check in eagle book
[EMAIL PROTECTED] (Eric Kolve) wrote: I was wondering if someone could explain to me why in the eagle book it is necessary to perform an md5 twice before sending a mac_check to a user of a number of fields. I read in the mod_perl book that this is done 'to prevent technically savy users from appending data to the @fields'. my $mac_check = md5_hex($secret, md5_hex(join '', $secret, @fields)); What I am wondering is, what situation would a user be able to append data to the fields? I believe if you change only one bit of the data, the mac will change, so I am a little confused. This looks suspicious to me too. Any hashing algorithm worth its salt shouldn't have to be done twice. And doing it twice may in fact expose weaknesses in the algorithm (though I have no evidence to support this). I'd suggest just this: my $mac_check = md5_hex join '', $secret, @fields; ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
Re: mac_check in eagle book
On 2001-04-15 23:52:38, [EMAIL PROTECTED] wrote: I was wondering if someone could explain to me why in the eagle book it is necessary to perform an md5 twice before sending a mac_check to a user [...] Any hashing algorithm worth its salt shouldn't have to be done twice. And doing it twice may in fact expose weaknesses in the algorithm (though I have no evidence to support this). Doesn't the Eagle book mention somewhere that this is done because of a known weakness in the MD5 algorithm? - ams
Re: mac_check in eagle book
Abhijit Menon-Sen [EMAIL PROTECTED] writes: On 2001-04-15 23:52:38, [EMAIL PROTECTED] wrote: I was wondering if someone could explain to me why in the eagle book it is necessary to perform an md5 twice before sending a mac_check to a user [...] Any hashing algorithm worth its salt shouldn't have to be done twice. And doing it twice may in fact expose weaknesses in the algorithm (though I have no evidence to support this). Doesn't the Eagle book mention somewhere that this is done because of a known weakness in the MD5 algorithm? There is a theoretical weakness in md5 if the attacker can create both sets of data that are hashed. Under some strict circumstances, he could get two different files with the same hash value. However, the real world risk of this is supposedly quite low and the attack is computationally difficult to perform. The double hashing reduces the risk further. The modperl book mentions it double hashes to prevent a malicious user from concatenating data onto the values being checked. I don't know if they are referring to this weakness, but I suspect they are. Sadly, the book doesn't seem to offer a reference for the claim as to the specific md5 vulnderability. (Hey Doug, wanna shed some light on that somewhat cryptic passage? :) It's been a while, but I believe SHA1 has yet to have a weakness found. md5 is probably secure enough for websites though. Chip -- Chip Turner [EMAIL PROTECTED] RHN Web Engineer
