Juerd has asked for the wisdom of the Perl Monks concerning the following question:

Okay, let's try again - my w3m discarded my previous post while posting, so the text was lost.

Can mod_perl be used to configure Apache on the fly, while running? I've been using mod_perl for a few weeks now, and haven't yet read everything there is to read. Because of the enormous speed increase, I'd like to let other users use mod_perl instead of CGI+Perl. However, the interpreter inside of Apache scares me a bit: can a user do things I don't want him to? (Read the configuration, or maybe even change it? Add handlers for other sites?)

Is mod_perl safe enough to let others use it?

- Yes, I reinvent wheels.
- Spam: Visit eurotraQ.

Replies are listed 'Best First'.
Re: mod_perl, configuration, security
by drewbie (Chaplain) on Apr 23, 2002 at 20:52 UTC
    First, you can use <Perl> sections to configure Apache. But I believe you can only do this in the httpd.conf & PerlRequire files. <Perl> sections are very cool, but from what I've seen to have some bugs you might have to work around. I've never used them personally, but many folks do. They work well, and can save lots of tedious work in httpd.conf

    To answer your second question, yes, your users can potentially use the mod_perl API to do nasty things. You can read some of the configuration through $r->server->xxx methods. See pg 455 in the Eagle book.

    Depending on how much power you grant to .htaccess files, you can do some interesting things in setting PerlHandlers. The major problem is that everything is cached in RAM. And there are ways to get to the stored values.

    Bottom line: if you trust the users on the system, go for it. If you're worried about kiddies, you should forgo mod_perl. I hope some of these potential security problems are addressed in mod_perl 2, but I don't know.

Re: mod_perl, configuration, security
by Fletch (Bishop) on Apr 24, 2002 at 03:15 UTC

    You can't do a lot of the configuration that can be done in <Perl> sections after the configuration is parsed (e.g. set the server admin), but you can do things like change handlers (see the push_handler and set_handler methods).

    And if you haven't gotten it, I'll reccomend the mod_perl Developer's Cookbook (ISBN 0672322404) for the second time today. It's a good companion to the ORA Eagle book (read that first if you're not familiar with the apache request cycle; then read the cookbook to find out common idioms and best practices).

Re: mod_perl, configuration, security
by trs80 (Priest) on Apr 23, 2002 at 22:59 UTC
    Just because it can't be said enough, read the mod_perl guide.
    I know Juerd has most likely already done this, but anyone that has not yet done so and is wanting to use mod_perl, stop and read the guide. The whole thing. It is a little ill organized, but then the amount of information and the area in which is related to is sometimes difficult to know. But it IS worth the time. I have solved +95% of my mod_perl issues by looking in the guide.
Re: mod_perl, configuration, security
by perrin (Chancellor) on Apr 23, 2002 at 22:06 UTC
    The biggest problem is that mod_perl lets people execute code as the same user who runs the web server, and you can't change that. It's also possible to mess with other people's code running in the same server, since Perl has no concept of security between classes.

    It's definitely not safe from malicious users.