(I'm assuming *nix here)

You need the directories to be writable by the webserver, which is usually the user called "nobody".

What I like to do is to set the group ownership to nobody, then set them user and group writable.

update: you might not be able to set group ownership to nobody if you're not root. If this is the case, you will have to ask your sysadmin to do it. (there is probably no workaround)
--
Snazzy tagline here

Hmmm. But if I am another user on this box, I can set up a cgi script to update this data, because my cgi script is also run by the server as nobody. Yes?

If you have root access or a friendly sysadmin, ask them to install cgiwrap. Then you can run scripts as yourself, and set datafile permissions to 600. The cobalt RaQ servers come with cgiwrap seamlessly installed (not a plug, have had both good and bad experiences with these).

Alternatively, you can set the effective uid of the script with chmod u+s (I'm sure there are tutorials - I'm a little fuzzy on this as I use cgiwrap). Or write a C wrapper for the script and suid that (more robust for scripts that use system or backticks I think - but again, I'm not sure about this either, so look around).

.02

cLive ;-)

Depending on your security needs... running your script as your user account will expose your personal data if there is a security bug. And that could be bad... particularly if you are using private key authentication, or have sudo access to some parts of the system. Whereas, if the webserver is compromised, you're exposing everybody's web data, probably the ftp server also, but not much else.
--
Snazzy tagline here

Aighearach is correct.
Generally you can only set the group ownership if you are a member of the new group to which you are changing or root under *nix

This also has the effect of limiting the scope of your scripts to effecting only those files which the user has write access to. Thus you don't have the problem of any user with group "nobody" effecting files written by another user also under the group "nobody".

This does mean you are still subject to the problem mentioned above of any files written by the website user will be at the mercy of scripts running from the website.

As an aside, I like the looks of cgiwrap mentioned above.

If you are concerned about other idiots on the same box as yours causing damage, one solution is to get a colocated server thus removing the other idiots on the box and narrowing the scope of idiots to just one. ;-)

If the project is worth the $300 to $500 per month of most colocated servers this might be an option.

Hope this helps
Claude

p.s. A word to wise when creating script which directly modify files on your website HTTP_REFERER is not a trusted field. Paranoia is your friend. Taint is a must.

Top of each script I write looks like this:

#!/usr/bin/perl -wT
use strict;
[download]


:) This idiot doesn't have near that type of cash for this type of job. I don't have to worry about other idiots on the box either though... Thanks Claude...

There's a couple ways to get around this.

There's suexec (it's an automatic cgiwrap). This will run all cgi programs and scripts under a given user and group. This way you can have all your scripts, programs, datafiles and stuff rw to that user.

If you're using mod_perl, you can't use suexec. suexec works only with mod_cgi spawned processes. You can run an apache process as a normal user, and use mod_proxy to push the requests back and forth.

If you're working under a hosted environment, things get a little hairier. Most likely the above two options will not be available to you. You're probably working with mod_cgi and everything runs as nobody, httpd, www-data or similar. You can work around this, chmod the parent directory 777 and have a script make all the directories you need apache to write to. Request that script in your browser. Then immediately chmod 711 the directory you just changed to 777. You'll now have your needed directories created and owned by the httpd process, you will be able to have your scripts write freely to these, without having world writable files and directories laying about.

Of course, a sometimes serious drawback to having the scripts create the directories and files is that, if you need to access/move files manually, you may not be able to. I struggled with this issue for quite a while, until I hit upon the idea of setting my data files to 666, the directory to 711, and putting both in a place inaccessable to the web. Since the cgi script runs on the server, but many of the security risks are reduced by placing the world-writable files in a non-world-readable place.

Just my 2¢

Spacewarp

DISCLAIMER:
Use of this advanced computing technology does not imply an endorsement
of Western industrial civilization.

This of course depends on your app, but if it ports well you can try using a database to store the data. You don't have to worry about file permissions that way--just set up a user account for access to the database. But I know that this isn't a viable option in a lot of cases....