SMF Support > SMF 2.0.x Support

Convert SMF to PHPBB

<< < (4/5) > >>

Arantor:
There are interesting side effects too - you won't be able to, for example, put the forum in maintenance mode or change its title because that's in Settings.php and that won't be writable. And you won't be able to use the in-built language editor for handling changes.

But if you had files owned by the webserver user, making them 644 doesn't save you anything at all, such that even CrawlProtect can't help you...

All we're doing here is figuring out how to put a band-aid on a much larger problem.

engrz:
please visit www.engrz.com and suggest me about changes in the forum. for example title, looks, themes. i also want to change footer. there is a lot of links.

MrPhil:

--- Quote from: Arantor on May 09, 2012, 11:31:06 AM ---Trouble is there are certain things (notably attachments) that must be 777 in order to work.

--- End quote ---

Not true. All that is required is that PHP be able to write to that directory. Depending on how your server is set up, the correct permissions might be 755 (PHP is running as owner), 775 (PHP is running in your group), or even 777 (PHP is some other random user). If 777, if possible, directories requiring that should be changed back to 755 after doing any uploads, although for attachments/avatars that may be difficult to do (without members losing the ability to load attachments or avatars).

Sorry, but a blanket statement that "such and such director(ies) should be 777" is irresponsible and leads to security breaches. SMF needs to be updated to find and use the minimum necessary permissions for a directory or file, and developers should consider making everything Read-Only but temporarily Write-Enabled as necessary for file writing operations.

Arantor:
Alright, if you're going to split hairs, yes, all it requires is for PHP to be able to write to that folder. On the vast majority of installs, the attachments folder will not be owned by the webserver, but by the FTP user - in which case the strong probability is that it will have to be 777. (I say this because in all standard Apache deployments, www-data or nobody is also in its own group, and PHP will be using that credential - in which case, 777 is the only thing that will work)


--- Quote ---Sorry, but a blanket statement that "such and such director(ies) should be 777" is irresponsible and leads to security breaches. SMF needs to be updated to find and use the minimum necessary permissions for a directory or file, and developers should consider making everything Read-Only but temporarily Write-Enabled as necessary for file writing operations.
--- End quote ---

Sorry, but a blanket statement that things should be lesser is also in itself irresponsible because it's also a cause of security breaches because you're only dealing with part of the problem.

So what if the folder is only 775 instead of 777? The real problem is still the fact that the web server can write to that folder. (Never mind the fact that on most shared hosts, Apache runs as www-data:www-data while users run as username:users and thus www-data won't even have group write access)

The files get saved by www-data (or nobody or whatever it is on your particular flavour), they're owned by that. Which means any other script on the server still can damage those files or write new ones. SMF is smart enough to deal with that by disallowing PHP execution on files in the attachments folder.

The cache folder, then, is a much greater risk of infection - and you can make that 775 or 755 and you're absolutely NO MORE SECURE than making it 777. Even making it read only doesn't solve the problem, it's still owned by the web server, it can still make them writable before writing.

Attachments, and cache, then have to be dealt with separately, but the single biggest security issue is the fact that files get made writable in order to install mods and then people don't change them back - and any file added by a mod that is not a standard SMF file can be made read only as much as you like, but it WILL NOT SOLVE THE PROBLEM. Especially if those files are attempted to be made 644 via FTP when they're not even owned by the FTP user.

While I appreciate where you're coming from (and believe me, I DO appreciate it where you're coming from, far more than most), if you're going to bawl people out, be thorough and explain all the consequences, not just the surface ones - if anything you're giving them a false sense of security by 'make it 755 and you'll be safe' when it really isn't true.

MrPhil:
What I object to is a blanket statement to just "make it 777" and everything will be all right. In the hands of naive forum administrators, this can lead to security problems on many servers (or, 500 errors when a "world writable" object is detected on some servers, which is better because at least it's been caught). Site owners need to understand permissions and what is the minimum necessary for any actor to perform their role on their particular server setup. In general, the more restrictive permissions are (so long as the application still works), the safer they will be. Thus, 755 is usually going to be safer for them (assuming SMF still works properly) than 777 is. All I'm saying is that if 755 (the safest) doesn't work, try 775 (less safe) before trying 777 (least safe). Don't just go blindly setting directories to 777 and then express surprise when they get hacked (if not through the Web interface, then through another user sharing their server).

Navigation

[0] Message Index

[#] Next page

[*] Previous page