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

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

Hi fellow monks,

I have a question about the best strategy for a problem I'm trying to solve. I am working on a rather large web-based database/content management project. Part of the goal is to make it as easy to install and use as possible - as well as make it useable in virtual hosting setups. What I'd like to do is have a script that is in the cgi-bin (or similar) directory be able to update itself as well as other .cgi scripts in that directory.

My initial thought is to use Net::FTP to grab the files from a pre-determined location (after determining whether an upgrade is available), create a backup directory to copy all existing files into, then grab the group of files from the server, and copy to the present location using Net::FTP. The primary issue I am dealing with here is permissions. I (or anyone with root access) can deal with it by changing ownership of the directory to the apache user. Also, obviously, making the directories world writeable is one other avenue (although I think not at all a good one.) But folks who have virtual host setups often cannot change the permissions on their files, or certainly not change the owner.

So, first, so I don't re-invent the wheel, any great Perl modules I should know about to do this sort of thing? And second, what would be the best strategy to deal with this?

Thanks!

Michelle

edited: Tue Jul 9 04:53:50 2002 by jeffa - title change

Comment on CGI script permissions for self-update (was: Strategy Question)

Replies are listed 'Best First'.
Re: Strategy Question by dws (Chancellor) on Jul 09, 2002 at 04:03 UTC
I am working on a rather large web-based database/content management project. Part of the goal is to make it as easy to install and use as possible - as well as make it useable in virtual hosting setups. MoveableType is a content management system, in Perl, that faces the same problem. They provide instructions for installing Perl packages that the host system may be lacking. MT takes some defensive measures in the code to disable features or downgrade performance if some optional packages aren't present. It's a free download. Check out how they do it. MT has a strong following, including non-technical people who've nonetheless overcome the hurl of installing Perl packages.	[reply]
Re: Strategy Question by Aristotle (Chancellor) on Jul 09, 2002 at 01:26 UTC
I'm not sure I like the idea at all, but one idea that comes to mind is letting an "installer script" create all the CGI scripts; they will then be owned by the user the webserver runs under. Obviously they will probably not be deletable via FTP, so you'll have to provide an "uninstall" script as well (or delete functionality in the setup script, anyway). If you really have to allow for some kind of self-update, I would strongly advise to have it all handled through a dedicated setup script rather than have the application script update itself. Makeshifts last the longest.	[reply]
Re: Strategy Question by perrin (Chancellor) on Jul 09, 2002 at 02:00 UTC
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.	[reply]
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.	[reply]
Re: Re: Re: Strategy Question by perrin (Chancellor) on Jul 09, 2002 at 02:30 UTC
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.	[reply]
Re: CGI script permissions for self-update (was: Strategy Question) by Abigail-II (Bishop) on Jul 09, 2002 at 09:03 UTC
Currently, I'm doing a gig for a bank. We have a complicated web based here, involving many servers (authentication, authorization, proxies, front-end application server, back-end application server, message routing, databases). Some servers are just used and don't contain anything specific to our application, but several others do; they are however shared with other applications (lots of virtual hosting going on here). We roll out a new version by doing an `swinstall` on three different machines (front-end, back-end, message router). We store all files in CVS and we use `ant` to build the depot files. `swinstall` is package system for HP-UX, comparable with Sun's package system. I don't know whether Redhats' `rpm` gives the same functionality. Abigail	[reply] [d/l] [select]
Re: CGI script permissions for self-update (was: Strategy Question) by little (Curate) on Jul 09, 2002 at 08:50 UTC
I'd rather recommend to allow updates in the form of a module not a script, as so you only have to worry about the permissions for the script and not the modules, just make sure that any added directories (for added modules) must be accesible to the user under wich the script (usually the same as the server) runs, but you can alternatively also call another script (preferrably outside your web servers SERVER_ROOT) which runs as a different user due its been setuid or so to have those directories created for you. Using modules to encapsulate all functionality you have all in handy to update your application entirely if the only scripts in front just use those modules. So you get stuck only in case that the script that looks for updates would need an update and does not store its functions in a module. Otherwise the script can do so easily, as as long as it runs to update itself all loaded modules remain available, so you just got the problem to step out and reload the script along with its modules again. Have a nice day All decision is left to your taste	[reply]