r.joseph has asked for the wisdom of the Perl Monks concerning the following question:

I have a large CGI system that my company uses that I developed for generating dynamic webpages. This system is large and has been developed by me over a few years. The website that it runs on will soon be webmastered by a perl novice who does not want to mess with my system.

Here is my question: the script I wrote is run everytime a request is sent for this particular domain. To allow this new webmaster to add functionality to the system without having to edit the main file, I wanted to allow him to write special files (with a certain extension or some identifier) that are just perl files that the system would search for upon every execution, and if it found them, execute. I was thinking about just slurping the whole 'plugin' file and then eval-ing it.

Now, as long as he knows what he is doing and writes conservative and clean code, and as long as I come up with some way of making sure that the file is written by him and not by someone else (some kind of passcode or something - that is not important), is it safe to do what I am planning, ie: using eval to execute whole files like this?

It seems like it should work as long as I make sure to watch @! and what have you, but I just wanted to ask the best perlites I know what they thought. Thanks a bunch for your help!!

R.Joseph

Replies are listed 'Best First'.
Re: Using eval to create 'plugins'
by dws (Chancellor) on Jan 09, 2001 at 13:31 UTC
    What you're planning -- allowing a junior webmaster to update a production server -- is frought with peril. You can make it somewhat safer by providing the junior webmaster with a test environment that includes your script, running under the same web server. Require that he first test his "plugins" there.

    To be even safer, arrange for the production server to not accept a plugin unless it's been (successfully) run on the test server. Have the test server generate a special hash of the plugin, use it as the upload password, and have the production server re-check the hash against the plugin, discarding the plugin if they don't match.

    Digest::MD5 generates hashes. To prevent spoofing, append a known-to-the-system passphrase to the script before hashing.

[reply]
[d/l]
Re: Using eval to create 'plugins'
by eg (Friar) on Jan 09, 2001 at 14:01 UTC

    Well, I'm not going to say that this a Good Idea, but if you go with this sort of architecture, you ought to look into using do rather than eval.

    Note, with do, lexicals can't be seen by the included code so you need to do something like: 

    use CGI;
use vars qw/ $cgi /;

$cgi = new CGI;

do 'junior-webmaster-code.pl';

    [download]

    Hmm. With perl 5.6, I think you could use our here (can anyone confirm or deny? Thanks.)

[reply]
[d/l]
      Says eg:
      I think you could use our here (can anyone confirm or deny?)
      Confirm.

[reply]
Re: Using eval to create 'plugins'
by dave_aiello (Pilgrim) on Jan 09, 2001 at 18:09 UTC
    I would say that you could look at the Slashcode project for an idea of how to do this. Slashboxes in the Slashcode environment are eval'ed in the manner you suggest.

    I also like the approach suggested by the comment Re: Using eval to create 'plugins' from dws where he said that you could enforce testing on a development system by requiring a hash generated by Digest::MD5. You will never see an OpenSource project constructed this way, IMHO, because no project leader will want to require all implementations to have a separate staging environment. But, such a solution could work well in your case.

[reply]
Re: Using eval to create 'plugins'
by clemburg (Curate) on Jan 09, 2001 at 23:21 UTC

    You will want to read Practical Internet Groupware by Jon Udell, chapter 15. It may contain what you need.

    Christian Lemburg
    Brainbench MVP for Perl
    http://www.brainbench.com

[reply]
Re: Using eval to create 'plugins'
by sutch (Curate) on Jan 09, 2001 at 21:16 UTC
    I have a similar problem and have begun to read up on the Safe module. Check out Programming Perl, 3rd ed., pp. 576-81.
[reply]

Back to Seekers of Perl Wisdom