I've just installed Vanilla and am a little worried about the file permissions.
Having conf as 0777 on setup is probably unavoidable and probably okay. However, it would probably be a good thing to say (in large letters) that after the set up it can be set back to something a little more reasonable like 0755.
Since the install.php script is run by the server, it will be owned by whoever normally runs php scripts and therefore the files that it creates will be owned by whoever they need to be owned by. They can therefore have extremely restrictive permissions, namely 0600.
The only potential problem with this is that if I am not the same as the php-script user then I can't even read the files. However, there is no way on a standard EXT filesystem to distinguish between me and any other user in this case: to give me read access means giving all other users on the system read access and if the web directories are generally accessible, that's not okay! (Just to reassure anyone, I can still delete the files because I own the containing directory, I just can't read them).
The reason that that's not okay is that the MySQL database password is in one of those files so anyone with read access to that file can get the password. This doesn't sound like a good feature to me.
Unfortunately, as I don't own these files I can't change their permissions from the command line. So it has to be done within the script, and preferably when the files are created. The easiest way is probably just to add the line
umask(0077);
inside the CreateFile function.
For a more refined set-up, where just the database.php file is protected, this could be added just before the CreateFile function is called on the database.php file.
Of course, this prevents me from manually editting any of the files but then I couldn't do that anyway as they were all owned by the php script user.
On systems where every user also has their own unique group then one way around this would be to assign the group of the configuration files to my group. However, I don't know if this is testable within the install script nor how widespread this is.
My apologies for not making myself clear. I wasn't particularly asking a question as I fixed the issue for myself (by adding the 'umask' command). I was suggesting that there is a security issue with the installation instructions. There are really two issues.
In the installation, I was clearly told that I had to set the permissions on the main directory to 0777. However I was never told that I could reset it to 0755. This is my first issue. The only time it needs to be 0777 is during the initial install when the script is creating the main configuration files. After that, the script only needs to be able to modify those files and that can be done with 0755 on the main directory.
One of those files contains the password for the database. This should be protected as much as possible. It is protected from being sent out over the web by an internal check (this could be easily supplemented by an htaccess block) but could still be read by a local user. This is my second issue. Changing the permissions on this file to 0600 prevents the latter.
In my original post, I was trying to anticipate some problems that that might cause, and show that they were not really problems at all.
Later, when installing the DefaultIcon plugin, I found that that needed write access to a directory as well. Again, this is worrisome as the only way I can give the script write access to somewhere is to give everyone write access - my solution was similar: to temporarily give everyone write access, use a simple php script to create a suitable directory for the DefaultIcon plugin, then remove the write access again leaving the php user with a directory that it can play around with.
It might be useful to be able to (easily) allow the user to specify one directory owned by the php user where the script will put all the files that it ever needs to be able to modify (or create). This would avoid having to do hacks like the above.
Well, so I guess I am asking for a secure set up for the Vanilla directory structure, after all.