in reply to CGI script permissions for self-update (was: Strategy Question)

This is bad bad bad. Don't change the code as part of the installation. How will you test and debug that? How will people upgrade? Instead, use a configuration file to capture all the site-specific information. Search for configuration modules here or on CPAN to see some options.

Replies are listed 'Best First'.
Re: Re: Strategy Question
by michellem (Friar) on Jul 09, 2002 at 02:15 UTC
    The site specific info is already captured in a config file. I'm just trying to make this easy on people who might want to use this system - and, it would make it easier for me to maintain the installations I have, if I can have an easy way to upgrade the installation. I'm not thinking of changing the code, per se, but allowing folks to upgrade to a new (stable) version when it becomes available, in an easier fashion than grabbing the package, uncompressing it, picking out the files they need, and then uploading them to their cgi-bin.

    Think of it as a tiny, tiny version of apt-get or cpan. That's what I'm aiming for.

      Okay, sorry, I misunderstood your goal.

      The programs you mention (CPAN, apt-get) deal with this issue by running as root (or as the owner of the local perl libs in the case of a private install). You shouldn't make a CGI script that can modify files in cgi-bin because it's just not secure enough. Instead, either make them run a script from the shell on the remote machine, or make a script they can run locally that will update the remote files over FTP. If they put the files there in the first place, they must have FTP access to modify them.