Quote:
Originally Posted by sortie
I believe in tight security but not locking myself in with iron bars so that I burn to death if there's a fire.
I don't want security so tight between each room that I have to use an axe to quickly hack into the bathroom if I feel a really wet beer fart comming.
RE: larger than a CMS:
The same issue applies to a simple message board script. The script has to delete the files it creates or wack the file with something like chmod 4777 so the user can delete thru FTP on those type configurations.
I don't think either of those conditions are highly desired.
|
You can have more lax security on your own servers. When it's a Virtualhost running probably 200+ accounts, you have to be careful. They're trying to protect themselves, and their clients. Faulting them for letting you create a file you can't read really
isn't their problem.
That's why everyone on shared accounts constantly get their pages defaced - usually due to some old unpatched WordPress bug, linkex, etc.
The script should be able to delete it's own files, but the script should also chmod the files, or set the umask itself when creating them. If you don't set the umask in FTP (which is usually 022 for files), obviously, you'll need to alter that with your FTP client, since there's no concept of octal permissions on Windows.
If your FTP account isn't the same user and group as the webserver, you create a 'cleanup' script, which someone runs from their browser, which will unlink the files and send out a 'cleaned up' or 'file removal failed' message. It's trivial, at best.