Package manager file permissions / chmod 666

[argimiro]

I am copying some files to the server using the package manager:

Code Select Expand


<?xml version="1.0"?>
<!DOCTYPE package-info SYSTEM "http://www.simplemachines.org/xml/package-info">
<package-info xmlns="http://www.simplemachines.org/xml/package-info" xmlns:smf="http://www.simplemachines.org/">
<id>iBookDB.net_with_SouthportFriends.co.uk:FacebookIntegration</id>
<name>Facebook Login Integration</name>
<version>0.0.12</version>
<type>modification</type>



<install for=""1.1 - 1.99.99"">
<readme>readme-fb.txt</readme>
<modification>install.xml</modification>
<require-file name="SMF1/ajaxresponder.php" destination="$boarddir" />
<require-file name="SMF1/verifylogin.php" destination="$boarddir" />
<require-file name="externallogin.php" destination="$boarddir" />
<require-file name="externalloginengine.php" destination="$boarddir" />
<require-file name="fbintsetts.php" destination="$boarddir" />
<require-file name="gigya.jpg" destination="$boarddir" />
<require-file name="facebook.png" destination="$boarddir" />
<require-file name="XHconn.js" destination="$boarddir" />
</install>

<uninstall for=""1.1 - 1.99.99"">
<readme type="inline">This will remove the mod files but not yet the extra database table</readme>
<code>droptable.php</code>
<modification reverse="true">install.xml</modification>
<remove-file name="$boarddir/ajaxresponder.php" />
<remove-file name="$boarddir/externallogin.php" />
<remove-file name="$boarddir/externalloginengine.php" />
<remove-file name="$boarddir/fbintsetts.php" />
<remove-file name="$boarddir/verifylogin.php" />
<remove-file name="$boarddir/gigya.jpg" />
<remove-file name="$boarddir/facebook.png" />
<remove-file name="$boarddir/XHconn.js" />
</uninstall>



<install for="2.0 - 2.99.99">
<readme>readme-fb.txt</readme>
<modification>install.xml</modification>
<require-file name="ajaxresponder.php" destination="$boarddir" />
<require-file name="externallogin.php" destination="$boarddir" />
<require-file name="externalloginengine.php" destination="$boarddir" />
<require-file name="fbintsetts.php" destination="$boarddir" />
<require-file name="verifylogin.php" destination="$boarddir" />
<require-file name="gigya.jpg" destination="$boarddir" />
<require-file name="facebook.png" destination="$boarddir" />
<require-file name="XHconn.js" destination="$boarddir" />
</install>

<uninstall for="2.0 - 2.99.99">
<readme type="inline">This will remove the mod files but not yet the extra database table</readme>
<code>droptable.php</code>
<modification reverse="true">install.xml</modification>
<remove-file name="$boarddir/ajaxresponder.php" />
<remove-file name="$boarddir/externallogin.php" />
<remove-file name="$boarddir/externalloginengine.php" />
<remove-file name="$boarddir/fbintsetts.php" />
<remove-file name="$boarddir/verifylogin.php" />
<remove-file name="$boarddir/gigya.jpg" />
<remove-file name="$boarddir/facebook.png" />
<remove-file name="$boarddir/XHconn.js" />
</uninstall>



</package-info>


This all works just fine for SMF 2.0 RC1.2 on my server which is:

Apache/2.2.11
Linux
2.6.18-53.1.14.el5PAE #1 SMP
i686
mod_ssl/2.2.11
OpenSSL/0.9.8e-fips-rhel5 DAV/2
mod_auth_passthrough/2.1
mod_bwlimited/1.4
PHP Version 5.2.10

Except that - the php files, once placed by the package manager, are chmodded 666.

Normally when I use my FTP client ALFTP 5.1, ASCII uploaded php files end up chmod 644.

When the files have 666 permissions, they won't run, they give a 500 Internal Server Error.

So what I'm having to do is, once my mod has installed itself, I have to go in via FTP & put all the php scripts back to 644.

The mod then works pretty flawlessly - any idea what I might be doing wrong to cause the 666 permissions?

[tyty1234]

It could be the settings of your FTP Client. Try FileZilla, it has proven to be a success by many users across the country.

[argimiro]

Yes I have & like FileZilla as well as ALFTP however, both these programs actually work okay - using either, I can upload php files manually to the server via ASCII transfer mode, when they arrive on the server they have the permissions '644', and they run just fine.

The problem manifests when it is the SMF 2.0 RC1.2 package manager itself that places the files on the server. When the package manager does it, my mod seems to cause the files to have permissions '666', and under those permissions, they won't run on my server.

So I figure either I am doing something wrong in my mod coding as regards the package manager, or else there's some strange incompatibility going on with my server config?

[argimiro]

Still foxed on this one but have updated title because I've noticed - it's not just happening on SMF2. My SMF 1.1.10 board acts the same way - it installs the package just fine, but chmods the php files as 666.

Yet other mods install and run just fine on both boards - so I guess it has to be a fault in my manner of putting the package together?

The package itself is available at the following address if someone needs to look at the code in detail:

http://www.simplemachines.org/community/index.php?topic=311025.msg2281462#msg2281462

[tyty1234]

Have you contacted your host already? And what errors are you getting in your forum error log?

[argimiro]

I haven't yet approached the host on this issue, no.. my line of thinking being, if other mods install just fine and seem to be able to place .php files with workable permissions okay, then it's less likely to be a server misconfiguration?

Regards errors in the log, none.. I just end up with a fully installed mod, which won't run without producing the 500 internal server error, because the files are 666. Chmod them manually to 644 using any FTP client & bingo, mod starts working!

[Norv]

Hello, can you please tell, is this still an issue?

If yes, can you please clarify what you mean by "other mods install just fine", does that include mods that add folders or files themselves?

[argimiro]

Hi Norv, yes, I never did get right down to the bottom of this.

All I did in the end, was to write code which checked the existing permissions of SMF's existing index.php, then whatever those permissions were on any particular server, CHMOD the mod's files the same. This worked as a solution but couldn't help feeling I was using a bodge to get round a lack of my knowledge in package assembly.

Regards "other mods install just fine",  and whether that includes mods that add their own files and / or folders, yes I think so. For instance I have E-arcade, yshout, both of which add both folders and php files.

Interestingly though, when I just went onto my FTP to check that, I noticed that both E-arcade and yshout both CHMODded their files 666 - and yet those mods both operate fine under those permissions.

It only seems to be when *my* mod package places a file on the server, that the CHMOD 666 seems to become a problem, and trying to run that file then produces a 500 error. Manually (or programatically, post-placement) CHMOD it to 644, and bingo it starts working. No other changes neccessary.

[Norv]

I think that the webserver logs, if available, might tell something helpful.

[argimiro]

I'm on a shared host with cpanel 11 - there is an option under 'Logs' called 'Error log' which displays "the last 300 errors for your site":

This function will display the last 300 errors for your site. This can be very useful for determining what links are broken on your site, or what files do not exist that should. Checking this log frequently can help keep your site running smoothly.
Last 300 Error Log Messages in reverse order:

Nothing is showing here after the installer has run.

However after the very first attempted run of the mod itself, after a 'successful' install:

[Sun Oct 18 00:24:34 2009] [error] [client xx.xx.xx.xx] File does not exist: blah/public_html/archive/500.shtml
[Sun Oct 18 00:24:34 2009] [error] [client xx.xx.xx.xx] SoftException in Application.cpp:256: File "blah/public_html/archive/externallogin.php" is writeable by group

Should I be asking the host for a different log?

Wondering if 666 is allowed to run okay if another php script is calling it, but it needs to be 644 if it's called directly as a url?

[Norv]

Wondering if 666 is allowed to run okay if another php script is calling it, but it needs to be 644 if it's called directly as a url?

That's what I am wondering too, but honestly I don't know, and I am a little too tired right now to be searching for suPHP documentation. But it must be something like this, or certain function calls on a file with these or those permissions. I'd say it clearly depends on what your mod actually does.

[argimiro]

The mod is a fairly simple ajax-based facebook integration. The file that raises the 500 error after mod installation is the mod's front-end which is largely external to SMF. Here is the content of that file:

Code Select Expand


<?php

echo'<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>Facebook Quicklogin (beta)</title>
</head>
<body>
<h1>Facebook Quicklogin (beta)</h1>
<!-- BEGIN CONTENT -->';
include_once('externalloginengine.php');
echo'<!-- END OF CONTENT -->
</body>
</html>
';
?>


I tried commenting out the include_once('externalloginengine.php'); however, even with that line commented out, permission 666 still raises a 500 error on that file.

If it's just the case that 666 actually should be working on my server in this circumstance, and the SMF package manager's CHMODding 666 normally works on everybody else's servers.. then it's a simple case that my host has performed a misconfiguration I guess, and I'll take it up with them..

I have come across other references to suPHP in relation to 666 / 644 / apache issues, yes..

This is what I am doing currently to get round it:

Code Select Expand


<?php

if(file_exists(dirname(__FILE__).'/SSI.php')&&!defined('SMF'))
   {require_once(dirname(__FILE__).'/SSI.php');}   
    else
     {if(defined('SMF')){global $scripturl;}else{die('chmod failure');}}

// CHMOD all the mods files as per whatever we find the permissions of index.php to be
if (fileperms($boarddir . "/index.php") != fileperms($boarddir . "/ajaxresponder.php"))
   {
   $existingpermissions = fileperms($boarddir . "/index.php");
   chmod($fbi_forum_root_directory . "ajaxresponder.php", $existingpermissions);
   chmod($fbi_forum_root_directory . "verifylogin.php", $existingpermissions);
   chmod($fbi_forum_root_directory . "externallogin.php", $existingpermissions);
   chmod($fbi_forum_root_directory . "externalloginengine.php", $existingpermissions);
   chmod($fbi_forum_root_directory . "fbintsetts.php", $existingpermissions);
   chmod($fbi_forum_root_directory . "XHconn.js", $existingpermissions);
   }

?>


[Aleksi "Lex" Kilpinen]

Hi argimiro, has your workaround solved this for you, or is there something you need assistance with still?

I'm unsure as to how exactly the package manager works out the right permissions to use though.

[argimiro]

I'll mark it solved since there doesn't seem to be an obvious answer, yes the workaround is doing the trick, it just seems kinda odd.. feels like I'm leaving some sort of gremlin in there somewhere!