NYCPHP Meetup

[csnyder]

On 5/7/05, David Mintz <dmintz at davidmintz.org> wrote:

> Doesn't it seem that the s?ftp cure would have to be coded with the utmost
> care or it might be worse than the disease, especially on a shared host?
> For example, if username/password are embedded in PHP scripts that
> themselves are world-readable... It would be interesting to see an example
> or psuedocode/outline showing an implementation.

You are exactly right. 

It depends on which is more distasteful in a given situation:
world-writeable directories and files, or the possibility that another
user will discover the (s)ftp password embedded in a configuration
file. On a shared host, and particularly for a cache, it's probably
preferable to have nobody own the files then to risk exposing your
password to all other scripts on the box.

But for the caching example, the workaround could be that you render
the pages on a local server that you control, which then (s)ftps them
to a shared host that has a public address and scads of bandwidth. Not
unlike Blogger, really.

A better but more complex workaround could be that files are uploaded
to a world-writeable directory that works as a drop box. A cron job,
running as you, could check the drop box for new files now and then,
and copy them to a normal directory with correct ownership and
permissions. It should compare the file with a hash stored in a
database to ensure that the file wasn't modified by someone else in
the meantime. The webserver will need to clean up the drop box
directory, since you won't be able to delete files owned by nobody.

Three parts to that, but I think it solves most of the problems
without storing a password or implicitly trusting what are, for all
practical purposes, world-writeable files.

----
Chris Snyder
http://chxo.com/