On Mon, Aug 16, 2010 at 11:27:23AM +1200, Brenda Wallace wrote:
the installer currently suggests the following:
Cannot write config file to: /home/brenda/workspace/statusnet
On your server, try this command: chmod a+w /home/brenda/workspace/statusnet
I'd like to change this to
On your server, try this command: touch
/home/brenda/workspace/statusnet/config.php; chmod a+w
/home/brenda/workspace/statusnet/config.php
(as well as a few other change to support this, they're all in the installer.)
This limits the amount of damage a future code bug can do.
What we did for MediaWiki's installer was to have it request that only
the installer's subdirectory be made writable, and then have the user
move the config file up again to the main level.
I like this 'create a writable but empty file' idea even more; it's
easily detectable and doesn't expose anything new that wasn't already
exposed; still simple directions, and doesn't require moving anything
afterwards.
It also will leave you with correct file ownership on the config.php
file, which can be a problem right now -- the web server ends up owning
the file if it's created by the installer, and this sometimes mucks up
later editing.
On 8/16/10 1:29 AM, Brenda Wallace wrote:
On Mon, Aug 16, 2010 at 5:09 PM, Aaron Toponce<[email protected]> wrote:
It's a rather poor suggestion to tell the user to 'chmod a+w' anything
on the system. Only the webserver needs write access, along with the
owner of the file. No one else should need write access, especially the
config.php. In fact, the read bit should be removed on that file, if
any.
i agree that changing ownership of the file is more secure, the target
audience for this is mostly people who do not have root access on
their server. Those who do have root are likely to know to chown files
instead.
We can word the message to suggest this, but as advice to newbies it's
not helpful unless they also have root.
Yeah, that's the main problem: we can give better advice, but it gets
longer, more complicated, becomes more error-prone, and is less likely
to even be available to the people who most need the instructions.
My long-term preference would be to default to database storage for
attachments and avatars, which requires no filesystem write permissions
(but does require a PHP invocation for each image load -- a performance
trade-off). We don't have the abstraction needed for that yet, though,
so no hurry. ;)
-- brion vibber (brion @ status.net)
_______________________________________________
StatusNet-dev mailing list
[email protected]
http://lists.status.net/mailman/listinfo/statusnet-dev
