Re: ErrorDocument 401 problem..
"DJ (David J Radunz)" wrote: > How i expected the ErrorDocument directive to behave was as follows: > WHEN there was an error 401 (ie the user had logged in 3 times and failed) > there would be an error page shown (in this case it would be /error/401). The issue of how many tries the user gets is separate. What I want you to do quickly is check to see what code your server is returning when the user sees your error page. Just use "lynx -dump -mime_header http://your-url/"; or "GET -s -d http://your-url/"; and tell us what code you see. Is it a 401? I'd just like to be sure the 401 is there before I try to help. -- Richard Goerwitz [EMAIL PROTECTED] tel: 401 438 8978
Re: HTML forms and piplining templating systems
Matt Sergeant wrote: > But then if you're happy with EmbPerl, why switch? A couple of reasons, really: 1) well, I actually wouldn't switch per se; people think in different ways, and it's often useful to support (and feel comfortable with) different development paradigms 2) EmbPerl is great, but if you're undisciplined it's very easy to mix content and presentation Like a lot of other people, I suspect, I've written my own ad hoc pipelining templating system several times over. E.g., when I did a system in 1997 called the Quran Browser http://www.stg.brown.edu/webs/quran_browser/ I created a back end that vended just the text, with very simple markup. The HTML is all added by the front end. While this made maintenance easy in some respects (you can add new texts, replace old ones, etc. without changing having to do much work on the front end), I found that pipelining tended to make the front end (in AxKit terms, the stylesheet) unnecessarily complex and hard to maintain. For very simple systems, it's not a big deal. But the more complex and interactive the system is, the more I actually have come to prefer the callback paradigm (like Embperl). The problem here is that if you're not careful, the callback para- digm leads to the very sort of mixing of content and presentation that makes changing either very difficult (e.g., try upgrading an Embperl system from HTML to XML, or even XHTML). So actually I'm not looking to move away from Embperl towards AxKit so much as try to keep my foot on both sides of the line. The call- back paradigm is good for some things. And the pipelining is good for others. Is AxKit the best of the pipelining breed, though? (I personally am finding XML to be a ghastly, ugly thing; it all started with namespaces, which are implemented via attributes in a horribly kludgy way - and now we're finding new schema mechanisms entering in, plus complex and unintuitive beasts like XSL. So I wonder just how slick AxKit can possibly be, given its foundation in these technologies.) -- Richard Goerwitz [EMAIL PROTECTED] tel: 401 438 8978
HTML forms and piplining templating systems
I've been using Embperl happily for several years now, and the only
real drawback I've seen to it was (until recently) that it lacked a
mechanism for doing inheritance/cascading. EmbPerlObject seems to
remedy this deficiency.
I've been hearing lots about AxKit lately.
I'm curious about one thing: How easy is it to do fill-out forms
with pipelining templating systems like AxKit? I'd think that in
such cases the stylesheet would have to do so much work that it
would become, in essence, like a CGI script. In other words, the
neat separation between content and presentation would be lost be-
cause the presentation of the form doesn't have much to do with
its "content" ("content" meaning the textual information on which
it's based).
Anyway, I'm just curious about forms and pipelining templating
systems generally. Does this really work? Work well?
--
Richard Goerwitz [EMAIL PROTECTED]
tel: 401 438 8978
Re: ErrorDocument 401 problem..
"DJ (David J Radunz)" wrote: > I have written a perl module called Apache::ErrorControl which I am > using to control the output of error messages from the server, and allow my > users to have custom error pages etc... You might want to re-think how you have this set up. I don't know how exactly you have your module coded, but just out of curiosity, is the user seeing a 401 response code - or a 200 res- ponse code? Or something else? If the user isn't seeing the 401 response code, there's not going to be any opportunity for him or her to authenticate. -- Richard Goerwitz [EMAIL PROTECTED] tel: 401 438 8978
Re: Doing Authorization using mod_perl from a programmers perspective
Jon Robison wrote: > Someone please tell me if I am wrong - does the USER_AGENT field get > some kind of special serial number from the browser, or is it just a > version identified? > > Best example - large company with 1000 PC's, all with same Netscape > installed. How then does the HTTP_USER_AGENT field deliniate between > PC's? I've been out of town and am coming at this thread late. In case nobody else has mentioned it, HTTP_USER_AGENT values are 1) non- unique, and 2) often shared by applications on a single host (true especially for Microsoft environments). -- Richard Goerwitz [EMAIL PROTECTED] tel: 401 438 8978
Re: Problem with Directory in Perl sections
James Stalker wrote:
> Does anyone here have Directory working in Perl sections in mod_perl
> 1.25 or above?
It's funny that you mention this because, now that I think
about it, I always set up directory and location blocks inside
virtual host blocks, e.g.:
$VirtualHost{"_default_:80"} = {
ServerName => $hostname,
DirectoryIndex => 'index.html index.shtml index.epl',
etc...
Location => {
'/admin/perl-status' => {
SetHandler => 'perl-script',
PerlHandler => 'Apache::Status'
},
etc...
},
FilesMatch => {
q(.*\\.epl$) => {
SetHandler => 'perl-script',
PerlHandler => 'HTML::Embperl',
Options => '+ExecCGI'
},
etc...
},
Directory => {
directory stuff goes here
}
}
--
Richard Goerwitz [EMAIL PROTECTED]
tel: 401 438 8978
Re: [OT] Re: What hourly rate to charge for programming?
> > > Now take the amount you want to make and divide it by the number > > > of hours you came up with above ($40,000 / 1,000). You get $40. > > > That's your target hourly rate. > > > > $40K as a consultant is much less spendable money than $40K as an > > employee. > > Yes, that's an additional 7.5% for social security. In addition, you > have to take care of your own benefits, etc. > > I'd recommend that you start to inch up your rate with new clients, > and that you try and see what your market will bear. I agree with this; but at the same time take your own circumstances into consideration: If you're young, don't live a profligate life- style, and like people and work, then don't worry about the money so much. Someone suggested charging $100/hour - more for mod_perl work. I have a different slant. I like mod_perl and like to encourage its use. I charge the same rate to everbody whether it's mod_perl or not. And I also usually try to work training into contracts; i.e., I try to work things out so that I not only cut mod_perl (or Emb- perl) code for clients, but also get to train their people on what I'm doing, if they aren't already intimately familiar with the tech- nology. Sometimes, actually, training is all the client wants. Another thought: For clients who keep coming back for more work, and who are flexi- ble about schedules, you should consider charging a lower rate. It is extremely valuable to have clients around that you can go to when you're "between" other jobs. Hang onto them. Give them a break if that helps. My _family_ actually sometimes pressures me to lower rates. I've been doing work lately for (among others) a big environmentalist nonprofit near Washington. My fifteen year-old son, who is a rabid environmentalist, said I should charge them less because the work they are doing is so valuable to the community. I told him it meant less money in his pocket as well as mine. He said he didn't care, so I dropped my rates ten percent :-). The bottom line is that it's really not about the money. If you're good and you like people, and you don't think God put on earth to drive a BMW and eat out every night, then you'll find you can get along quite well charging reasonable rates. Your clients will love you. You'll be a happy guy. And you'll help spread open-source technology all around. -- Richard Goerwitz [EMAIL PROTECTED] tel: 401 438 8978
Re: What hourly rate to charge for programming?
Philip Mak wrote, asking about whether he's chargin the right hourly rate. He describes his background as: > > I've had about two years of experience with perl, and one year of > experience with mod_perl and MySQL. Business was so-so for me last month; everybody froze up. I feel for you if you're consulting. So let me offer you some advice. Take it for what it's worth ;-). The formula is this: Figure out what you want to make - something appropriate given your experience and ability, and the region in which you typically operate. Let's start with a nice round figure of $40,000 US dollars. Take the number of working hours in a year and divide them in half (40 hours a week * 50 working weeks a year) / 2 = 1000 hours. (The idea is that you shouldn't be billing more than half your working hours; if you are, then you aren't doing other things you need to do in order to sustain a business.) Now take the amount you want to make and divide it by the number of hours you came up with above ($40,000 / 1,000). You get $40. That's your target hourly rate. And despite what they high-flying .com weanies were saying a year ago, that's going to be a nice living for a young guy unless you're smack in the middle of a high-cost area and can't bother to cook your own meals. Money doesn't make you happy. (I lived like a church mouse as a grad student with my wife and son, and really those were the best days of my life!) After you've been working for 5+ years and have a lot of refer- ences and repeat business, you'll be able to charge considerably more because you'll just be faster at what you do and capable of writing better, more reliable systems and code. (I am a much, much better Perl coder than I was seven years ago when I first started using it. I rarely have any problems with those silly tests some employers dump on you when you first negotiate a con- tract; usually I end up correcting a few mistakes on the part of the testers. And I'm a decent mentor to junior programmers. As a result I charge a lot more. And I'm able to compete favorably against big shops who hire programmers out for $120-300 per hour, especially in major urban areas.) About the billable hours thing: You really have to be careful not to overbill. If you do some code that's usable by more than one current client, don't charge them both. And make sure to give them good reports on what you're doing. Clients like to know what they're paying for. If you're not sure how long a job will take, negotiate a stepped contract in which you spend, say, a week working on a problem then report on your progress at the end of the week so you and your employer can decide whether it's worth going on to the next step. There's an old joke about a consultant who dies at age 42 of a heart attack. You have to be a Christian of some stripe to find this funny, so my apologies to Muslims, Hindus, etc. Anyway, he ascends to the pearly gates and, upon meeting Saint Peter, accosts him saying, "Why was I taken so young? I was only forty-two!" Saint Peter fumbles with his books a moment and responds, "That's funny, but according to your billing records you're seventy three." -- Richard Goerwitz [EMAIL PROTECTED] tel: 401 438 8978
Re: segfault w/ Apache 1.3.20, mod_perl 1.26
Ged Haywood wrote: > IIRC there was a problem with the compiler (gcc) that came with RH7.0, > which compiler are you using? I'm using the patched version of GCC that RedHat later released, gcc-2.96-85. Dunno if it's relevant, but I see the following ChangeLog entry that might or might not be relevant to this problem (for mod_perl 1.25_01 - July 6, 2001): adjust perl_clear_symtab() to deal properly bleedperl's version of cv_undef() (which broke modules with directive handlers) thanks to Geoffrey Young for the spot On perl_clear_symtab() see below. Note that I tried both mod_perl 1.26 and 1.26_01, and both behave similarly. I.e., both coredump after handling all the commands in my section. The coredump happens inside Perl_sv_free: #0 0x81fe1d2 in Perl_sv_free () #1 0x81d5e84 in Perl_cv_undef () #2 0x80acba9 in perl_clear_symtab () The message in my error_log file is: Attempt to free unreferenced scalar. > Send us the output of "perl -V" and also the arguments you gave to > Makefile.PL, then when they all get back from the conference maybe > someone will have your answer. Ok, first the Makefile.PL args. I tried this various ways (e.g., with and without PERL_DEBUG; also, with just PERL_TRACE): SSL_BASE='/usr' perl Makefile.PL APACHE_SRC=/usr/local/src/apache/src USE_APACI=1 EVERYTHING=1 PERL_DEBUG=1 ADD_MODULE=all DO_HTTPD=1 APACI_ARGS='--enable-module=all' Here's my perl -V output: Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration: Platform: osname=linux, osvers=2.2.17-8smp, archname=i386-linux uname='linux porky.devel.redhat.com 2.2.17-8smp #1 smp fri nov 17 16:12:17 est 2000 i686 unknown ' config_args='-des -Doptimize=-O2 -march=i386 -mcpu=i686 -Dcc=gcc -Dcccdlflags=-fPIC -Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux -Dd_dosuid -Dd_semctl_semun -Di_db -Di_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Uuselargefiles' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=undef d_sfio=undef uselargefiles=undef use64bitint=undef use64bitall=undef uselongdouble=undef usesocks=undef Compiler: cc='gcc', optimize='-O2 -march=i386 -mcpu=i686', gccversion=2.96 2731 (Red Hat Linux 7.1 2.96-78) cppflags='-fno-strict-aliasing' ccflags ='-fno-strict-aliasing' stdchar='char', d_stdstdio=define, usevfork=false intsize=4, longsize=4, ptrsize=4, doublesize=8 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=4 alignbytes=4, usemymalloc=n, prototype=define Linker and Libraries: ld='gcc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -ldl -lm -lc -lcrypt libc=/lib/libc-2.2.so, so=so, useshrplib=false, libperl=libperl.a Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic' cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: Built under linux Compiled at Apr 3 2001 11:27:33 @INC: /usr/lib/perl5/5.6.0/i386-linux /usr/lib/perl5/5.6.0 /usr/lib/perl5/site_perl/5.6.0/i386-linux /usr/lib/perl5/site_perl/5.6.0 /usr/lib/perl5/site_perl . > Does this happen with a static build? Yes, indeed it does. -- Richard Goerwitz [EMAIL PROTECTED] tel: 401 438 8978
More information on segfault
More information on segfault (apache-1.3.20, mod_perl 1.26_01, perl 5.6.0 [default RedHat 7.0 installation of Perl plus modules]). I've compiled in tracing and now at least pinpoint the command that's causing the problem (yes, I have mod_ssl-2.8.4-1.3.20 compiled in as well): SVt_PV: $SSLPassPhraseDialog = `'exec:/usr/local/sbin/echo-server-privkey-password'' handle_command (SSLPassPhraseDialog 'exec:/usr/local/sbin/echo-server-privkey-password'): OK Program received signal SIGSEGV, Segmentation fault. 0x81fe1d2 in Perl_sv_free () (gdb) bt #0 0x81fe1d2 in Perl_sv_free () #1 0x81d5e84 in Perl_cv_undef () #2 0x80acba9 in perl_clear_symtab () #3 0x80ad38f in perl_section () #4 0x818cdf8 in invoke_cmd () #5 0x818d90e in ap_handle_command () #6 0x818d9a1 in ap_srm_command_loop () #7 0x818e00e in ap_process_resource_config () #8 0x818e943 in ap_read_config () #9 0x8198670 in standalone_main () #10 0x8198fab in main () #11 0x402f4b5c in __libc_start_main (main=0x8198bf8 , argc=4, ubp_av=0xb9c4, init=0x807d5d8 <_init>, fini=0x8235950 <_fini>, rtld_fini=0x4000d634 <_dl_fini>, stack_end=0xb9bc) at ../sysdeps/generic/libc-start.c:129 All this tells me is that the error is occurring after all the handle_command() calls are finished (SSLPassPhraseDialog is the last one to be executed; if I remove the $SSLPassPhraseDialog = statement it and put it outside a section, then the seg- fault happens anyway - after the last command gets handled). -- Richard Goerwitz [EMAIL PROTECTED] tel: 401 438 8978
segfault w/ Apache 1.3.20, mod_perl 1.26
I apologize if this problem has already been identified and solved. After upgrading from mod_perl 1.25 to mod_perl 1.26 I fired up an Apache server instance that uses a config file with an extensive set of sections. I'm using the Perl that came with my Linux (RedHat 7.0) machine, namely 5.6.0. I'm just wondering if the following trace looks familiar to anyone: Program received signal SIGSEGV, Segmentation fault. 0x81fc2c2 in Perl_sv_free () (gdb) bt #0 0x81fc2c2 in Perl_sv_free () #1 0x81d3f74 in Perl_cv_undef () #2 0x80ab249 in perl_clear_symtab () #3 0x80ab8cf in perl_section () #4 0x818aee8 in invoke_cmd () #5 0x818b9fe in ap_handle_command () #6 0x818ba91 in ap_srm_command_loop () #7 0x818c0fe in ap_process_resource_config () #8 0x818ca33 in ap_read_config () #9 0x8196760 in standalone_main () #10 0x819709b in main () #11 0x402f4b5c in __libc_start_main (main=0x8196ce8 , argc=4, ubp_av=0xb9e4, init=0x807d58c <_init>, fini=0x8233a40 <_fini>, rtld_fini=0x4000d634 <_dl_fini>, stack_end=0xb9dc) at ../sysdeps/generic/libc-start.c:129 -- Richard Goerwitz [EMAIL PROTECTED] tel: 401 438 8978
Re: an unusual [job request] + taking mod_perl to the commercial world
barries wrote: > > Anyway, this seems promising. Where I know we wouldn't pay money to fund an > > entire year of Stas developing mod_perl solely, I certainly know that there > > are probably features I would seriously consider sponsoring. > > Any others out there that might be interested, let's hear from you :-). > My employer's on the rocks, so no easy money there I'm finding (while doing consulting work) that, if I already have an "in" with a firm, I can usually leverage that to work in time training the staff in how to use mod_perl indirectly, by teaching them Embperl first. Embperl ends up being the draw. I find I can take average Perl programmers and get them up and run- ning with Embperl, basically in two sessions. And once they figure out what all they can do - and how quickly all their Perl scripts can transfer - they buy right in. The main hurdle turns out to be working a build of mod_perl into the servers they're using. Often quite a number of developers are all at work, and they don't all merit the kind of trust that mod_perl requires. Mod_perl, though, is a pretty trusting module. -- Richard Goerwitz [EMAIL PROTECTED] tel: 401 438 8978
Re: Bug (easily fixable) in Apache::Server
The mod_perl-1.24_01 ./src/modules/perl/Server.xs file is using a short int, which leads to ports between 32768 and 65535 (inclusive) turning up in Perl as negative numbers - short port(server, ...) Apache::Server server CODE: RETVAL = server->port; if(items > 1) server->port = (short)SvIV(ST(1)); OUTPUT: RETVAL -- Richard Goerwitz[EMAIL PROTECTED]
Re: fork inherits socket connection
Stas Bekman wrote: > > 1. Start the long running process (runs indefinitly for the > >purpose of this test), which closes STDOUT, STDIN and > >STDERR and then calls setsid(). > > Why do you call setsid()? He's probably thinking of traditional the traditional way in which you background a daemon by forking, setsid'ing, then forking again to prevent the process from ever reacquiring a controlling terminal (your point, that this isn't needed here, is well taken). -- Richard Goerwitz[EMAIL PROTECTED]
Re: security suggestion
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 can only use specific modules (or modules in specific places)
> > 2) users can't (by implication) use Apache::Registry unless I say so
> > 3) users can't change PERL5LIB or use PerlSetEnv (or PerlPassEnv)
> > 4) users can't include any Perl code indirectly or otherwise (e.g.,
> > sections, literal 'sub { ... }'s as handlers)
>
> ...I would advocate an ExecModPerl option or something like that so that
> user's could not arbitrarily install their own Perl Handlers.
Some thoughts:
If a user has ExecCGI privileges he or she can commandeer the most important
part of the request cycle (the response phase), so I'm not sure we get
better
security or control by having a separate ExecModPerl option.
NB: If we re-use ExecCGI for mod_perl, people will feel as though they're
on familiar turf. Sysadmins will understand the implications of turning it
on (i.e., they'll know that turning it on means the ability to execute code
on the server, using the ID under which Apache runs). And re-using ExecCGI
would relieve us of having to reserve another (mostly redundant) word.
--
Richard Goerwitz[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: security suggestion
"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 would be executed? (I'm not disputing anything you say; just trying to follow.) -- Richard Goerwitz[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: security suggestion
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::TransHandler"
>
That's a neat idea.
The only quibble I can think of is that this doesn't go far enough.
This lower level of privilege we're talking about is one in which -
1) Only specific Perl modules are available (or ones in specific
paths; no literal 'sub { ... }' handlers)
2) PerlSetEnv (and PerlPassEnv?) aren't usable
3) PERL5LIB isn't changeable
4) sections are unavailable
--
Richard Goerwitz[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: security suggestion
"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 modules currently do (in the sense that they let you offer developers, users, etc. access to the module without letting them execute arbitrary code on the server). Would you agree that this would be a good thing? Your solution above is great. But it's another one of those "I have a workaround" suggestions. I wonder if there is a way to skip the workarounds. If there is, would you agree that it would be a good (no, wonderful) thing? And would you agree that, if it's possible to do it, mod_perl would be more useful if it were set up in such a way that merely enabling it didn't essentially give everyone with access to the webserver's docroot the ability to execute arbitrary Perl? I'm interested in knowing what's possible here. My knowledge of mod_ perl right now is pretty good, from a module developer's standpoint. I'm just not familiar enough (yet) with its internals to be able to think and speak creatively about the security possibilities. -- Richard Goerwitz[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: security suggestion
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 it be a counter, a new authentication method, a
special content handler, or just some thingie I wrote for them). I think
it would be great to be able to offer web publishers the ability to _use_
those modules without giving them direct access to Perl.
Not all shops consist of a small group of twenty-something developers who
all eat pizza and beer together on Fridays. Many of us operate in hetero-
geneous environments with hundreds, if not thousands, of web "developers"
who are part of our community, and who may really need some custom modules
written for them, but who I can't be bothered monitoring on a day-to-day
basis - and who I don't want to grant blanket access to my server inter-
nals to.
Let me return to my C module analogy. When I compile in mod_auth_dbi, I
am giving users added functionality. But I'm not giving them the ability
to execute arbitrary C code. I think everyone would agree that this is a
useful (no, critical) feature of Apache.
I simply want to be able to do the same thing in Perl with mod_perl. I
want to be able to give developers ("users" - whatever you want to call
them) added functionality, without giving them the ability to execute
arbitrary Perl code.
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). I don't know
what else would need to be done, but it all strikes me as critical to
the use of mod_perl in shops that don't fit the "pizza and beer" model
that something along these lines be done.
--
Richard Goerwitz[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: security suggestion
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 where I disagree. Perl modules often offer extremely useful
functionality. They often do things that even ordinary web developers
might want to do. So I think it's imperative that ordinary web devel-
opers be able to install canned mod_perl handlers that I've written
for them (or installed for them).
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 to allow it.
But that doesn't mean I want to cut them off from modules I've made
available myself.
Think of it as being like C modules. Say I want to give them access
to a built-in counter module. I compile the C module and either load
it dynamically, or build it statically into Apache and enable it.
Either way, they get access to the counter module's functionality.
But the don't, as a side-effect, get to execute arbitrary C code.
Perl modules should work the same way. I should be able to give them
access to existing modules without giving them access to Perl. If I
want to give them access to Perl, I should have to do it explicitly.
I've advocated co-opting ExecCGI for this purpose.
We could go the mod_include route, of course, where you get #exec
by default, and only lose #exec via IncludesNoExec.
That could work, too.
> PERL_SECTIONS=0 at build time can deactivate this across the board
IMHO it shouldn't be an all-or-nothing thing.
--
Richard Goerwitz[EMAIL PROTECTED]
Re: security suggestion
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 - unless, of course, they can ExecCGI. The general idea is this: Regular users without ExecCGI may have good reason to say things like, PerlAuthenHandler Apache::SomeNewAuthModule E.g., suppose you want them to be able to use some local secure cookie- based auth handler. Or they may want to use a locally written response handler that converts HTML to XHTML on the fly - or innumerable other modules. Although we want those users to have access to these modules (and to the added functionality they bring), we may not want them to be able to execute arbitrary Perl code. And if we DO want them to execute arbitrary Perl code, we should have to explicitly grant them permission to do it. Permission shouldn't be granted implicitly by doing something else (e.g., by enabling another module like mod_perl). My sense is that the existing ExecCGI mechanism is a perfectly reasonable way of handling the permissions here, since being able to execute arbi- trary Perl code is basically the same as ExecCGI privileges (it's a bit more powerful, but why introduce more options if we don't really need to?). -- Richard Goerwitz[EMAIL PROTECTED]
security suggestion
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 ExecCGI does. How does it do this?
Well, for one thing, you can inject arbitrary Perl code at any stage in
the Apache request cycle by using a literal
PerlWhateverHandler 'sub { ... }'
in an htaccess file. You can also specify
PerlWhateverHandler Some::Arbitrary::Path::To::An::Arbitrary::Module.pm
I've been thinking that, since giving users the ability to do these
things is essentially like giving them ExecCGI privileges, that these
things should only be allowed where the ExecCGI option is turned on.
There's also the problem, if a person can ExecCGI, that they can then
use Apache (), and then access all dir_config, notes, and other settings.
At times it may be useful for a systems administrator to create private
dir_config variables that run-of-the-mill CGI scripts simply can't see.
These are two separate issues, of course.
The more pressing one, I think, is the first, namely that we need to
tie the ability to use arbitrary Perl subroutines and arbitrary Perl
modules (i.e., modules in non-system paths) to the ExecCGI option.
I realize that forcing us all to turn ExecCGI on for directories where
we want to use arbitrary Perl subroutines would be a bit of a pain at
this point. So for the current 1.24_0x series I'd suggest adding some
new "paranoid" compile-time option that would deny arbitrary subs and
modules in non-system paths unless ExecCGI is enabled. Another idea
that I haven't really thought through would be to create some new
PerlLiteralSubs On|Off directive that could not be overridden once
turned on.
For the future, though, it might be useful to tie arbitrary subs and
the ability to use Perl modules to ExecCGI. ExecCGI-like privileges
something a sysadmin should always have to decide to do. My sense is
that they should never be turned on implicitly, e.g., by simply adding
and enabling a module.
Does this make sense to anyone else?
--
Richard Goerwitz[EMAIL PROTECTED]
Re: security suggestion
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]
segfault on DBI->connect (was Re: Apache segfault)
Trond Arve Nordheim wrote, re the "segfault on DBI->connect" problem: > I found out that using all mod_perl-versions between 1.22 and 1.24 with DBI > causes this segfault (Thanks to obscurite, #linux@efnet :) > So, after downgrading my mod_perl to 1.21.3, everything works fine... AT > LAST! ;) Compile PHP using --with-mysql=/usr (or whatever turns out to be the appropriate way of telling PHP not to use its own internal mysql library on your platform). -- Richard Goerwitz[EMAIL PROTECTED]
Re: mod_perl: Configuration info at run-time
Matt Sergeant wrote:
> > > for ($s = Apache->server; $s; $s = $s->next) {
> > > my ($server, $port) = ($s->server_hostname, $s->port);
> > > $r->print('server: ', $server, "\n");
> > > $r->print('port: ', $port, "\n");
> > >
> > > my $subreq = $r->lookup_uri("http://$server:$port/");
> > > $r->print('variable value: ', $subreq->dir_config('SomePerlVariable'),
>"\n");
> > > }
> Why don't you just try it? It should work regardless. The auth stuff
> should only happen if you actually call $subreq->run()
Thanks for that pointer re subreqs and auth. I appreciate it.
For whatever reason, when I try this, though, dir_config() doesn't pick
up any of my Perl variables, even though it (naturally) has no trouble
doing this when called in the usual way (e.g., $r->dir_config()).
My configuration is pretty vanilla: RedHat 6.1 w/ from-scratch builds
of Perl 5.00503, Apache 1.3.12, mod_perl 1.24.
--
Richard Goerwitz[EMAIL PROTECTED]
Re: mod_perl: Configuration info at run-time
Matt Sergeant wrote:
> OK then, try this:
>
> for ($s = Apache->server; $s; $s = $s->next) {
> my ($server, $port) = ($s->server_hostname, $s->port);
> $r->print('server: ', $server, "\n");
> $r->print('port: ', $port, "\n");
>
> my $subreq = $r->lookup_uri("http://$server:$port/");
> $r->print('variable value: ', $subreq->dir_config('SomePerlVariable'), "\n");
> }
Ah. But what if the server is running SSL - or what if the root page is
protected by basic or some other such form of auth or access control? I
can work up some elaborate setup in which a request from the server's own
IP address will pass all these checks. Or I can push auth modules that
return OK on non-main requests.
But this is pretty scary--and hard to maintain as servers change IP ad-
dresses or DNS names shift (yes, we can handle the address/name shifts
via sections, but this seems overkill for what [I had thought]
would be a simple problem that should have been an easy solve).
(As you said, one would think that dir_config [called on a server object]
should have done the trick.)
--
Richard Goerwitz[EMAIL PROTECTED]
Re: mod_perl: Configuration info at run-time
To get a list of virtual servers -
> > > for (my $s = Apache->server; $s; $s = $s->next()) {
> > > print "Virtual host: ", $s->server_hostname, "\n";
> > > }
> > Is there any reasonable way to use the list of servers (successive
> > values of $s above) to determine what mod_perl PerlSetVar directives
> > have been issued for each virtual host?
> >
> > E.g., is there some clever way to use Apache::ModuleConfig->get ()
> > to do this?
>
> $s->dir_config() should work.
You've actually hit upon my original reason for writing. For whatever
reason, the following code doesn't work for me. The dir_config routine
doesn't find what it's looking for (although it should - or at least so
I thought):
sub handler () {
my $r = shift;
my $vserver;
$r->status (OK);
$r->content_type ('text/plain');
$r->send_http_header ();
for ($vserver = Apache->server; $vserver; $vserver = $vserver->next) {
$r->print ('server: ', $vserver->server_hostname(), "\n");
$r->print ('port: ', $vserver->port(), "\n");
$r->print ('variable value: ', $vserver->dir_config
('SomePerlVariable'), "\n");
}
etc.
--
Richard Goerwitz[EMAIL PROTECTED]
Re: mod_perl: Configuration info at run-time
In response to my query about how to get a list of virtual
servers, Matt Sergeant wrote:
> It's server->next():
>
> for (my $s = Apache->server; $s; $s = $s->next()) {
> print "Virtual host: ", $s->server_hostname, "\n";
> }
Here's a followup:
Is there any reasonable way to use the list of servers (successive
values of $s above) to determine what mod_perl PerlSetVar directives
have been issued for each virtual host?
E.g., is there some clever way to use Apache::ModuleConfig->get ()
to do this?
--
Richard Goerwitz[EMAIL PROTECTED]
Re: Caching and mod_perl
Regarding my question about mod_perl access to Apache caching utilities, [EMAIL PROTECTED] wrote: > See page 120 in the Eagle book for If-Modified-Since caching, using > update_mtime and set_last_modified. Except for the creation of temp > files and unlinking, this is somewhat similar to what > ap_proxy_cache_update is doing in mod_proxy. Maybe I read that chapter all wrong, but I thought the problem to be solved there was that of providing clients with enough information to effectively cache what, in fact, was a dynamically generated navigation bar. What I'm interested in knowing is whether anybody's written an inter- face to the actual Apache caching utility routines. -- Richard Goerwitz[EMAIL PROTECTED]
Caching and mod_perl
Is there a mod_perl interface to caching routines available via the C api (e.g., mod_proxy's ap_proxy_cache_update()--or to any other low- level caching utilities)? -- Richard Goerwitz[EMAIL PROTECTED]
mod_perl: Configuration info at run-time
It's not obvious to me how one might get a list of VirtualHosts that are configured for the current server instance (at run-time, e.g., from in- side a Perl module). Is there some canonical way to do this? -- Richard Goerwitz[EMAIL PROTECTED]
Re: Segfault on DBI->connect
Many of us have been experiencing segfaults on DBI->connect when using the
DBD-mysql
drivers.
I wonder if anyone has found a solution.
I've appended a pretty comprehensive overview of the problem below.
Problem description: Child Apache process segfaults on DBI->connect with
Apache
1.3.12 and Msql-Mysql-modules-1.22{11,12,13,14} (maybe other versions,
too). This
happens with mod_perl versions 1.22 through 1.24. I happen to be running
RedHat
6.1 with egcs-2.91.66, but I've built everything (from Perl to Apache) from
scratch.
Anyway, the point of failure has been found: the MySQL mysql_real_connect()
routine called by Msql-Mysql-modules-1.22{11-14} gets passed a NULL first
arg.
So far nobody has figured out what is going on here, and why this problem
has only now started to crop up. It seemed to appear when I upgraded
mod_perl
to 1.22 and Apache to 1.3.12.
Here's one of my low-level traces. Farther below I offer a DBI->trace(9)
trace,
which shows what's going on from Perl/DBI/DBD's point of view.
> Running Apache with a -X argument yields the following backtrace when my
> mod_perl module does a DBI->connect (str, username, passwd, { options }).
> Note the null mysql argument
> |
> v
> #0 0x80ef5b7 in mysql_real_connect (mysql=0x0,
> host=0x8a99db8 "catlin.cis.brown.edu", user=0x8a9b550 "proxystuff",
> passwd=0x8a9b568 "Kui0-,12!", db=0x8a99e40 "proxysession", port=3306,
> unix_socket=0x0, client_flag=0) at libmysql.c:1125
> #1 0x402d01fd in mysql_dr_connect ()
> from /usr/lib/perl5/site_perl/5.005/i386-linux/auto/DBD/mysql/mysql.so
> #2 0x402d0540 in _MyLogin ()
> from /usr/lib/perl5/site_perl/5.005/i386-linux/auto/DBD/mysql/mysql.so
I really don't know how the null first argument is getting passed to
mysql_real_connect.
Here's a DBI->trace (9) of what's going on. I confess that I don't
understand
most of this output (which comes from my Apache error log file):
> DBI 1.13-nothread dispatch trace level set to 9
> ->
>DBI->Apache::DBI::connect(dbi:mysql:database=proxysession;host=catlin.cis.brown.edu;port=3306,
> proxystuff, Kui0-,12!)
> -> DBI->install_driver(mysql) for perl=5.00503 pid=14122 ruid=99 euid=99
> install_driver: DBD::mysql loaded (version 2.0414)
> New DBI::dr (for DBD::mysql::dr, parent=, id=)
> dbih_setup_handle(DBI::dr=HASH(0x858a0e8)=>DBI::dr=HASH(0x8930414),
>DBD::mysql::dr, 0, Null!)
> dbih_make_com(Null!, DBD::mysql::dr, 84)
> dbih_setup_attrib(DBI::dr=HASH(0x8930414), Err, Null!) SCALAR(0x89259cc) (already
>defined)
> dbih_setup_attrib(DBI::dr=HASH(0x8930414), State, Null!) SCALAR(0x858a3ac)
>(already defined)
> dbih_setup_attrib(DBI::dr=HASH(0x8930414), Errstr, Null!) SCALAR(0x89259e4)
>(already defined)
> dbih_setup_attrib(DBI::dr=HASH(0x8930414), Handlers, Null!) ARRAY(0x89304c8)
>(already defined)
> dbih_setup_attrib(DBI::dr=HASH(0x8930414), Debug, Null!) 0 (already defined)<-
>install_driver= DBI::dr=HASH(0x858a0e8)
> >> FETCH DISPATCH (DBI::dr=HASH(0x8930414) rc2/1 @2 g0 a866b270) at
>/usr/lib/perl5/site_perl/5.005/Apache/DBI.pm line 64.
> <- FETCH= 'mysql' ('Name' from cache) at
>/usr/lib/perl5/site_perl/5.005/Apache/DBI.pm line 64.
> >> connect DISPATCH (DBI::dr=HASH(0x858a0e8) rc1/5 @5 g0 a866b288) at
>/usr/lib/perl5/site_perl/5.005/Apache/DBI.pm line 120.
> -> connect for DBD::mysql::dr (DBI::dr=HASH(0x858a0e8)~0x8930414
>'database=proxysession;host=catlin.cis.brown.edu;port=3306' 'proxystuff' 'pKui0-,12!'
>HASH(0x892441c))
> New DBI::db (for DBD::mysql::db, parent=DBI::dr=HASH(0x8930414),
>id=HASH(0x8930450))
> dbih_setup_handle(DBI::db=HASH(0x89304a4)=>DBI::db=HASH(0x893a058),
>DBD::mysql::db, 8587d60, HASH(0x8930450))
> dbih_make_com(DBI::dr=HASH(0x8930414), DBD::mysql::db, 520)
> dbih_setup_attrib(DBI::db=HASH(0x893a058), Err, DBI::dr=HASH(0x8930414))
>SCALAR(0x89259cc) (already defined)
> dbih_setup_attrib(DBI::db=HASH(0x893a058), State, DBI::dr=HASH(0x8930414))
>SCALAR(0x858a3ac) (already defined)
> dbih_setup_attrib(DBI::db=HASH(0x893a058), Errstr, DBI::dr=HASH(0x8930414))
>SCALAR(0x89259e4) (already defined)
> dbih_setup_attrib(DBI::db=HASH(0x893a058), Handlers, DBI::dr=HASH(0x8930414))
>ARRAY(0x89304c8) (already defined)
> dbih_setup_attrib(DBI::db=HASH(0x893a058), Debug, DBI::dr=HASH(0x8930414)) 0
>(already defined)
> imp_dbh->connect: dsn = database=proxysession;host=catlin.cis.brown.edu;port=3306,
>uid = proxystuff, pwd = Kui0-,12!
> imp_dbh->MyLogin: dbname = proxysession, uid = proxystuff, pwd = Kui0-,12!,host =
>catlin.cis.brown.edu, port = 3306
> imp_dbh->MyConnect: host = catlin.cis.brown.edu, port = 3306, uid = proxystuff,
>pwd = Kui0-,12!
> imp_dbh->MyConnect: client_flags = 0
> [Wed May 17 11:17:29 2000] [notice] child pid 14122 exit signal Segmentation fault
>(11)
--
Richard Goerwitz[EMAIL PROTECTED]
Re: Segfault on DBI->Connect
We seem to be dancing around the DBI->connect segfault problem with MySQL
DBI drivers. Maybe someone here who reads other relevant lists could for-
ward our traffic and see if we can create some synergy there.
Our basic story is that, with Apache 1.3.12 and mod_perl 1.22 (with DBI
version 1.13 and Msql-Mysql-modules-1.2211), many of us are getting seg-
faults when we call DBI->connect. I happen to be running RedHat 6.1 with
egcs-2.91.66. Maybe this is a compiler issue.
Anyway, the point of failure has been found: the MySQL mysql_real_connect()
routine called by Msql-Mysql-modules-1.2211 gets passed a NULL first arg.
So far nobody has figured out what is going on here, and why this problem
has only now started to crop up.
Just to review, here are some relevant portions of our discussion thread.
(As I noted above, it might be really helpful if those with subscriptions
to related lists could repost this information appropriately.)
Relevant quotes:
> Running Apache with a -X argument yields the following backtrace when my
> mod_perl module does a DBI->connect (str, username, passwd, { options }).
> Note the null mysql argument
> |
> #0 0x80ef5b7 in mysql_real_connect (mysql=0x0,
> host=0x8a99db8 "hostname.brown.edu", user=0x8a9b550 "username",
> passwd=0x8a9b568 "password", db=0x8a99e40 "databasename", port=3306,
> unix_socket=0x0, client_flag=0) at libmysql.c:1125
> #1 0x402d01fd in mysql_dr_connect ()
>from /usr/lib/perl5/site_perl/5.005/i386-linux/auto/DBD/mysql/mysql.so
> #2 0x402d0540 in _MyLogin ()
>from /usr/lib/perl5/site_perl/5.005/i386-linux/auto/DBD/mysql/mysql.so
>
> The mysql_real_connect routine does a set_sigpipe(mysql), which triggers
> the segfault.
Here's one response -
>> Right, I had the exact same problem. Took me almost 1 day to solve.
>> I'm using apache 1.3.12 / mod_perl 1.22 / DBI 1.13 / Msql-Mysql-modules 1.22.11
>>
>> original code:
>> --
>> mysql_init(*sock);
>>
>> modified:
>> --
>> *sock = 0;
>> mysql_init(*sock);
(I'm not sure how well this will work, since the DBI driver for MySQL takes
elaborate measures to pass a pointer to a MYSQL struct into MyConnect, which
then gets initialized by mysql_init. The DBI driver relies on the
side-effect
of mysql_init initializing its first argument. So if we manually set *sock
to zero, other stuff might break.)
Richard Goerwitz
Brown University
Problems w/ CGI under mod_perl
Before I turn everything inside out, let me ask a quick question: Has
anyone encountered problems using CGI and CGI::Cookie with mod_perl? The
Problem I am noticing emanates from CGI->new(). Here's the section of
code:
if ($MOD_PERL) {
Apache->request->register_cleanup(\&CGI::_reset_globals);
undef $NPH;
}
The error I'm seeing is (taken from my Apache log files):
Wed Jan 19 11:33:45 2000] [error] Can't call method "register_cleanup" on an
undefined value at /usr/lib/perl5/5.00503/CGI.pm line 263.
Platform: RedHat Linux 6.1 + from-scratch build of Apache 1.3.9, mod_perl
1.21
I'll be happy to provide more details. I'd just like to take a first pass
at this, in case I'm doing something silly, i.e., overlooking something ob-
vious.
--
Richard Goerwitz[EMAIL PROTECTED]
