What are correct file permissions for 3.04? [message #167625] |
Wed, 08 August 2012 19:16 |
|
pyroxid
Messages: 15 Registered: August 2012 Location: Berlin, Germany
Karma: 0
|
Junior Member |
|
|
Hi FUDforum,
I recently upgraded a very old FUD 2.7.7 to 3.0.4, it was tough to do to save all the data, especially with Umlauts and everything, but I did it.
Just - all my files on the server have chmod 666 and the directories 777. I think this should not be the case, but I do not know which settings are recommended and whether there should be different file permissions for the data directory and the web directory. Could somebody please tell me what to set for the two (and maybe give a hint how to bulk this? It's a lot of files), it would be greatly appreciated. Thank you!
|
|
|
|
Aw: What are correct file permissions for 3.04? [message #167634 is a reply to message #167625] |
Sat, 11 August 2012 17:01 |
|
pyroxid
Messages: 15 Registered: August 2012 Location: Berlin, Germany
Karma: 0
|
Junior Member |
|
|
Hi,
thanks for your answer. I did not see an option to reset all files to original / recommended values? I know how to chmod a file, just not what the recommended permissions would be. For the meantime, I have set all files to 660 and folders to 771. Would this be considered safe / right or should I change it?
edit, oh, ok. just saw that recommendations are 0600 (0644 when using Apache) / 0700 (0711 when using Apache)
Thanks for all answers!
[Updated on: Sat, 11 August 2012 17:03] Report message to a moderator
|
|
|
Lockups with 500 error is caused by permissions [message #168845 is a reply to message #167634] |
Sun, 28 July 2013 21:37 |
|
Parrot
Messages: 32 Registered: July 2013 Location: US
Karma: 1
|
Member |
|
|
Summary:
Failures during installation and during operation with a "500 internal server error" are in some or all cases due to permissions.
After detailing what happens and what causes it, a possible solution is suggested for naudefj/Frank's decision.
Problem:
Installation kept failing with blank screens and, in the page source, a 500 error. Tried installing FUDforum 3041, 304, and finally 305RC1. Eventually tried changing all permissions from 777 to 775. Then it installed and worked. (Initial impression of FUDforum: very nice)
Soon after installation, the same error occurred. Blank screens from user interface and admin interface, again with the 500 error. Found the directories set at 777, apparently during installation. Changed them to 775. Then FUDforum started to work normally again.
Explored FUDforum for a couple of hours and changed some settings. Shortly after, the forum stopped working again. Sure enough, the directories I had set to 775 were changed by the software to 777. (BTW, I've been evaluating several forum products, most recently MyBB (pretty good), and none had this permission problem.) Asked host's tech support for help.
Cause:
My host refuses any file with 777 permission. Here are some explanatory quotes from their messages:
Quote:The 500 error was being generated due to incorrect permissions on your account. I have corrected the permissions
I have reviewed your account once more, and I found that your forum directory was set 0777 permissions. I also found 0777 permissions within the forum directory.
Please note that the security environment on HostGator servers disallows you from using 777 permissions and will return a 500 error if you have any files or folders set in such a manner on your account.
The likely reason that the script developers recommend 777 permissions is because the default environment they developed this software in may not have suPHP. In a default server environment, scripts that use PHP will run as a user called "nobody," which means that the the files that the script uses need to be set to 777 to even run. suPHP allows for scripts to run as a cPanel user instead of "nobody," which means that you can secure the script with 755 and 644 permissions instead. It also prevents you from being able to set different permissions that are higher than that. The 500 error simply prompts you to the fact that there is an error, and in our circumstance cannot be made more detailed.
I don't know about suPHP, etc., but presumably you will understand this.
In any case, they are unlikely to change their servers' security settings to accommodate FUDforum software.
Possible Solution:
FUDforum permissions seem to be set by the file [forum data path]/include/compiler.inc in several lines:
Line 740:
$perms = $GLOBALS['FUD_OPT_2'] & 8388608 ? 0700 : 0777;
if (strncmp(PHP_SAPI, 'apache', 6) && $perms == 0700) {
$perms = 0711;
Line 812:
if (!@is_dir($path) && !@mkdir($path, 0777)) {
throw new Exception('ERROR: Unable to create directory: '. $path .'.<br />');
Line 856:
if (!@is_dir($path) && !@mkdir($path, 0777)) {
throw new Exception('ERROR: Unable to create directory: '. $path .'.<br />');
Line 895:
if (!@is_dir($path) && !@mkdir($path, 0777)) {
throw new Exception('ERROR: Unable to create directory: '. $path .'.<br />');
Are permissions set by other FUDforum files?
An obvious solution to try is editing compiler.inc and changing all 777 to 775.
But FUDforum is not simple software. Its internal relations are complex and highly interactive.
That's why I'm asking you. What can I do to stop FUDforum from setting 777 permissions?
Thanks.
|
|
|
Re: Lockups with 500 error is caused by permissions [message #168851 is a reply to message #168845] |
Mon, 29 July 2013 14:41 |
|
Parrot
Messages: 32 Registered: July 2013 Location: US
Karma: 1
|
Member |
|
|
Added: Also had to correct the globals.php entry:
from: $GLOBALS['WWW_ROOT_DISK'] = '/home/[domain]/public_html/';
to: $GLOBALS['WWW_ROOT_DISK'] = '/home/[domain]/public_html/forum/';
Adding the forum's folder was necessary to let FUDforum find its files and run.
|
|
|
Re: Lockups with 500 error is caused by permissions [message #168854 is a reply to message #168851] |
Mon, 29 July 2013 19:22 |
|
Parrot
Messages: 32 Registered: July 2013 Location: US
Karma: 1
|
Member |
|
|
Added: Received a response from host's support:
Quote:
Due to the concerns raised, this ticket has been escalated... Unfortunately, as our servers use suPHP, there is not a way to allow scripts to run using 777 permissions. The majority of hosting companies now use suPHP servers, where 755 permissions will allow PHP to read, write and execute scripts like 777 does. Most scripts are now written with this in mind, but some rarer or custom scripts such as yours retain the use of 777.
In one of the recent responses I see that you have found a section of the script that sets the permissions to 777 and also mentioned that you were getting in contact with the developer to determine how to work around or update this option. As such, we'd like to ask if you've received any word back? Unfortunately this is not a script I've seen before, but often forums will have configurable options in the back-end to declare what permissions to use when a new file is created.
My reply to host:
Quote:Still waiting for developer's response, hopefully with clarification such as: Yes, go right ahead and edit the permission settings in that file. No other files do that. No other files need to be changed. No other files will check permissions and refuse to run or malfunction if not 777 or 666. That's what I hope to hear. I'll let you know.
Meanwhile, I'm manually changing the permissions every time the software thinks it knows better. That's only a minor annoyance since nobody else is using it yet.
But opening the forum to others will be impossible, since the software can set file permissions when users perform certain actions. Then, the server will freeze the forum without giving users a clue.
If the developer says it's ok to change that file and maybe other files or provides a revision to the software, that will solve the problem. I'll let you know.
|
|
|
Re: Lockups with 500 error is caused by permissions [message #168858 is a reply to message #168854] |
Tue, 30 July 2013 05:59 |
|
cpreston
Messages: 160 Registered: July 2012 Location: Oceanside
Karma: 6
|
Senior Member |
|
|
What suphp does is allow you to run php scripts as if they are being executed by the user that owns the files. Before suphp, such scripts would run as "nobody," which had a lot of issues, or were forced to run as root, which is BAAAD.
In an suphp/Apache based server, your website runs as a user that you log in as, and your scripts run as that user. So, in order to protect your user from running code it isn't familiar with, they protect the permissions of the files. That way, some other user can't overwrite the files with something else, causing your user to run some other script. Make sense?
I'm running FUDforum on a suphp server, and have no issues. All files are 644 and all directories are 755. This is how FUDforum did things during the install. Not sure how your permissions got messed up. As I read the lines of code you mentioned, they would only get called in certain circumstances. The last three are making a directory if it doesn't exist. In most cases, those directories would exist.
I've had web-based installs (like FUDforum) fail when I copied the files as root or my permissions were off when I copied them. Make sure all the files that get unzipped from the install file are 644 and all the directories are 755, and all should be well.
|
|
|
|
Re: Lockups with 500 error is caused by permissions [message #168861 is a reply to message #168858] |
Tue, 30 July 2013 18:57 |
|
Parrot
Messages: 32 Registered: July 2013 Location: US
Karma: 1
|
Member |
|
|
Thanks for your reply. Using 305RC1 (new install, not upgrade), it's behaving differently than you indicated.
Quote:All files are 644 and all directories are 755. This is how FUDforum did things during the install. Not sure how your permissions got messed up. As I read the lines of code you mentioned, they would only get called in certain circumstances.
Let's look at the "Lock" and "Unlock" function, starting with all folders 755 and all files 644:
--- (a)pressing Unlock changes some folders to 711. It also changes a few files (.htaccess) to 666.
--- (b) pressing Lock changes most folders to 777 except for a few changed to or left at 711. Many files become 666.
Of course that crashes the forum and requires manually resetting permissions to 755/644 to get it to work again.
Until the experts (you) figure this out, can I edit files to prevent setting 777?
Questions:
--- Any reason why I shouldn't edit compiler.inc and change 777 to 755 and 666 to 644?
--- Any other files that set permissions?
Thanks.
|
|
|
|
Re: Lockups with 500 error is caused by permissions [message #168863 is a reply to message #168862] |
Tue, 30 July 2013 23:49 |
|
Parrot
Messages: 32 Registered: July 2013 Location: US
Karma: 1
|
Member |
|
|
Thanks for the guidance. I'm brand new to FUDforum. When starting with new, complex software like FUDforum, I expect to bump into walls and trip over furniture while learning how to use it. That's ok. So far, I think FUDforum is worth the effort.
Why the beta? Attempted to install 3041, then 304, and finally 305RC1 before getting it to work, probably because that's when the permission issue became clear. If 305RC1 is working, I'll stick with it for now.
Quote:I will say that there's nothing wrong with resetting the files to the right permissions for you,
and then staying away from things that mess w/permissions. Or use them, but just know you're
going to have to fix them after.
Yes, I've been manually resetting permissions to 755/644 when FUDforum stops working. That's no problem, because for now nobody else will be using it. Obviously, the forum can't be opened to users until this problem is solved, be it a fix in FUDforum or (more likely) in something at my end.
Outstanding questions:
1. Any reason not to edit compiler.inc and change 777 to 755 and 666 to 644? Will that break any other functions?
2. Are there files other than compiler.inc that set permissions?
Thanks.
|
|
|
|
Re: Lockups with 500 error is caused by permissions [message #168865 is a reply to message #168864] |
Wed, 31 July 2013 00:51 |
|
cpreston
Messages: 160 Registered: July 2012 Location: Oceanside
Karma: 6
|
Senior Member |
|
|
Just for giggles I did do a complete search for 777, 666 and 711 to see how many files talk about changing permissions. There are a few.
I am not in production yet, but yes, i agree these need to be addressed and am surprised that no one has brought it up before.
Here's what I found. Please note the file name is UNDER the lines of code from that file, not above it.
#####################
#FUDforum directory:
#####################
$perms = $GLOBALS['FUD_OPT_2'] & 8388608 ? 0700 : 0777;
$perms = 0711;
if (!@is_dir($path) && !@mkdir($path, 0777)) {
$perms = $GLOBALS['FUD_OPT_2'] & 8388608 ? 0600 : 0666;
if (!@is_dir($path) && !@mkdir($path, 0777)) {
if (!@is_dir($path) && !@mkdir($path, 0777)) {
./include/compiler.inc
@chmod('msg_'. $s, ($GLOBALS['FUD_OPT_2'] & 8388608 ? 0600 : 0666));
./include/theme/default/imsg_edt.inc
@chmod($loc, ($GLOBALS['FUD_OPT_2'] & 8388608 ? 0600 : 0666));
./include/theme/default/attach.inc
chmod($GLOBALS['MSG_STORE_DIR'] .'private', ($GLOBALS['FUD_OPT_2'] & 8388608 ? 0600 : 0666));
./include/theme/default/private.inc
$perms = $GLOBALS['FUD_OPT_2'] & 8388608 ? 0600 : 0666;
$perm = 0777;
$perm = 0666;
./include/file_adm.inc
chmod($GLOBALS['MSG_STORE_DIR'] .'pages', ($GLOBALS['FUD_OPT_2'] & 8388608 ? 0600 : 0666));
./include/page_adm.inc
@chmod($loc, ($GLOBALS['FUD_OPT_2'] & 8388608 ? 0600 : 0666));
./src/attach.inc.t
@chmod($FILE_STORE . $aid .'.atch', ($FUD_OPT_2 & 8388608 ? 0600 : 0666));
./src/ppost.php.t
chmod($GLOBALS['MSG_STORE_DIR'] .'private', ($GLOBALS['FUD_OPT_2'] & 8388608 ? 0600 : 0666));
./src/private.inc.t
@chmod('msg_'. $s, ($GLOBALS['FUD_OPT_2'] & 8388608 ? 0600 : 0666));
./src/imsg_edt.inc.t
#################################
#/forum directory
#################################
@chmod('msg_'. $s, ($GLOBALS['FUD_OPT_2'] & 8388608 ? 0600 : 0666));
@chmod($loc, ($GLOBALS['FUD_OPT_2'] & 8388608 ? 0600 : 0666));
chmod($GLOBALS['MSG_STORE_DIR'] .'private', ($GLOBALS['FUD_OPT_2'] & 8388608 ? 0600 : 0666));
chmod($GLOBALS['MSG_STORE_DIR'] .'private', ($GLOBALS['FUD_OPT_2'] & 8388608 ? 0600 : 0666));
./theme/default/pmsg.php
chmod($GLOBALS['MSG_STORE_DIR'] .'private', ($GLOBALS['FUD_OPT_2'] & 8388608 ? 0600 : 0666));
./theme/default/thr_exch.php
@chmod('msg_'. $s, ($GLOBALS['FUD_OPT_2'] & 8388608 ? 0600 : 0666));
@chmod($loc, ($GLOBALS['FUD_OPT_2'] & 8388608 ? 0600 : 0666));
./theme/default/post.php
@chmod('msg_'. $s, ($GLOBALS['FUD_OPT_2'] & 8388608 ? 0600 : 0666));
@chmod($loc, ($GLOBALS['FUD_OPT_2'] & 8388608 ? 0600 : 0666));
./theme/default/modque.php
@chmod('msg_'. $s, ($GLOBALS['FUD_OPT_2'] & 8388608 ? 0600 : 0666));
@chmod($loc, ($GLOBALS['FUD_OPT_2'] & 8388608 ? 0600 : 0666));
./theme/default/movemsg.php
@chmod('msg_'. $s, ($GLOBALS['FUD_OPT_2'] & 8388608 ? 0600 : 0666));
@chmod($loc, ($GLOBALS['FUD_OPT_2'] & 8388608 ? 0600 : 0666));
./theme/default/mmod.php
@chmod($loc, ($GLOBALS['FUD_OPT_2'] & 8388608 ? 0600 : 0666));
./theme/default/getfile.php
chmod($GLOBALS['MSG_STORE_DIR'] .'private', ($GLOBALS['FUD_OPT_2'] & 8388608 ? 0600 : 0666));
@chmod($loc, ($GLOBALS['FUD_OPT_2'] & 8388608 ? 0600 : 0666));
@chmod($FILE_STORE . $aid .'.atch', ($FUD_OPT_2 & 8388608 ? 0600 : 0666));
./theme/default/ppost.php
chmod($GLOBALS['MSG_STORE_DIR'] .'private', ($GLOBALS['FUD_OPT_2'] & 8388608 ? 0600 : 0666));
./theme/default/pmsg_dump.php
$dirperms = 0777;
$fileperms = 0666;
$dirperms = 0711;
./adm/admlock.php
if (!@mkdir($cur_dir .'/'. basename($_GET['mkdir']), ($FUD_OPT_2 & 8388608 ? 0700 : 0777))) {
@chmod($fdest, ($FUD_OPT_2 & 8388608 ? 0600 : 0666));
./adm/admbrowse.php
if (!@is_dir($root_nn) && !@mkdir($root_nn, 0777)) {
mkdir($root_nn.'/tmpl', 0777);
mkdir($root_nn.'/tmpl', 0777);
./adm/admtemplates.php
$mode = ($FUD_OPT_2 & 8388608 ? 0600 : 0666);
./adm/compact.php
Although there are some repeated lines from above, these are the times I could find references to chmod or mkdir
fud_mkdir($GLOBALS['WWW_ROOT_DISK'].'theme', $perms);
fud_mkdir($GLOBALS['WWW_ROOT_DISK'] .'theme/'. $tname, $perms);
fud_mkdir($GLOBALS['INCLUDE'] .'theme', $perms);
fud_mkdir($GLOBALS['INCLUDE'] .'theme/'. $tname, $perms);
if (!@is_dir($path) && !@mkdir($path, 0777)) {
if (!@is_dir($path) && !@mkdir($path, 0777)) {
@chmod($file, $perms);
if (!@is_dir($path) && !@mkdir($path, 0777)) {
./include/compiler.inc
@chmod('msg_'. $s, ($GLOBALS['FUD_OPT_2'] & 8388608 ? 0600 : 0666));
./include/theme/default/imsg_edt.inc
@chmod($loc, ($GLOBALS['FUD_OPT_2'] & 8388608 ? 0600 : 0666));
./include/theme/default/attach.inc
chmod($GLOBALS['MSG_STORE_DIR'] .'private', ($GLOBALS['FUD_OPT_2'] & 8388608 ? 0600 : 0666));
./include/theme/default/private.inc
function fud_mkdir($path, $perms=0755)
if (!mkdir($dir, $perms)) {
if (!is_dir($d) && !mkdir($d)) {
chmod($d, $dperm);
@chmod($d, $perms);
if (!chmod($file, $perm)) {
./include/file_adm.inc
chmod($GLOBALS['MSG_STORE_DIR'] .'pages', ($GLOBALS['FUD_OPT_2'] & 8388608 ? 0600 : 0666));
./include/page_adm.inc
@chmod($loc, ($GLOBALS['FUD_OPT_2'] & 8388608 ? 0600 : 0666));
./src/attach.inc.t
@chmod($FILE_STORE . $aid .'.atch', ($FUD_OPT_2 & 8388608 ? 0600 : 0666));
./src/ppost.php.t
|
|
|
Re: Lockups with 500 error is caused by permissions [message #168876 is a reply to message #168865] |
Thu, 01 August 2013 15:14 |
|
Parrot
Messages: 32 Registered: July 2013 Location: US
Karma: 1
|
Member |
|
|
Yes, I did a similar search, but after finding and looking at the first few such files, it became clear that this is a job for the developers.
Forum software does a lot and is necessarily complex, with extensive internal interactions. If I try to modify it, it would do more harm than good.
> I'll leave those answers up to Frank or someone else more senior w/FF.
Me too.
|
|
|
|
|
Re: Lockups with 500 error is caused by permissions [message #168975 is a reply to message #168922] |
Mon, 12 August 2013 17:28 |
|
Parrot
Messages: 32 Registered: July 2013 Location: US
Karma: 1
|
Member |
|
|
Here's a helpful tool that sets all permissions in a folder, including its subfolders, to folders=755 and files=644. You can adjust that to suit your needs.
<html>
<head>
<title>Folder and File Permission Fixer</title>
</head>
<body>
<form name="form1" method="post" action="">
<?php
if ($_POST[d] == "Yes and Go") {
system ('find ./ -type f -exec chmod 644 {} \;');
system ('find ./ -type d -exec chmod 755 {} \;');
system ('find ./ -name \*.cgi -exec chmod 755 {} \;');
system ('find ./ -name \*.pl -exec chmod 755 {} \;');
system ('find ./ -name \*.pm -exec chmod 755 {} \;');
echo '</br>Done.';
} else {
echo'<h1>This utility will change the permissions to the parent and all of the parents subfolders.</h1><h3>(please place this file in the root of the public_html to be most effective.) </h3>';
echo'<h3>Set all Files = 644 ???</h3><h3>Set all Folders = 755 ???</h3><h3>Set all cgi and pl and pm files = 755 ???</h3>';
echo '<input type="submit" value="Yes and Go" name="d">';
}
?>
</body>
</html>
|
|
|
|
|
|
|
|
|
|