On host server servers that run PHP SUexec, Zenphoto's version 1.3.1 update process fails (500 server error) due to its insistence on making changes to file and folder permissions that are NOT allowed on such servers. PHP SUexec seems to make the Zenphoto set-up process think that the existing permissions are "loose" and, for example, it then chmods ALL of the zp-core files to 666 which halts the entire process immediately.
There may be other "workarounds", but I was able to succeed only by re-extracting the installation zip file package and thus re-setting all of its folder and file permissions to normal (755/644) AFTER passing that point in the Zenphoto set-up process.
Just thought that others installaing on host servers using SUexec (as lots do) might want to be warned.
Zenphoto
Comments
I can only tell you that I've never seen a problem quite like this one with any other PHP application installer, and I've used quite a few. In fact, most are satisfied to inform the user about required permissions and let it go at that. This is the first time I've seen a set-up procedure chmod all of the application's own core PHP scripts with 666 permissions. I can't image what circumstances would ever require that -- with or without SUexec!
And, incidentally, when it complained erroneously about "loose" permissions, I did tell it that I wanted them left as they actually were (0755/0644). Apparently it didn't accept that instruction.
Anyway Zenphoto will not "relax" any existing settings. But of course, if the server reports them more relaxed than they are/should be it will inadvertantly try to relax them.
PHP SUexec merely provides the facility to have all scripts running under the relevant user account instead of under the web server's account. There's no "lying" about folder and file permissions involved at all. In fact, The server can be made MORE secure if SUexec is properly deployed. The problem is that the Zenphoto's set-up process is misinterpreting the available PHP user account access as being due to "loose" file permissions and then making it worse by 666ing EVERYTHING in sight.
There is simply no valid reason for that, but I can see that I'm probably wasting my time on the subject. For myself personally, I found a "workaround" solution. I strongly suspect, however, that others may be less fortunate, and I can only wish you and them good luck in the circumstances.
__
P.S.: To avoid any possible misunderstanding, I actually like Zenphoto very much. My hope was that my "heads up" might provide and be taken as an opportunity to deal with an installation issue having some rather profound implications in today's rapidly evolving hosting environment.
The fault lies in that your server's SUexec environment doesn't permit these files to have permissions that "loose"; that behavior is defined by SUexec, not by Zenphoto. SUexec attempts to correct the permissions to what it thinks is secure, which may or may not work correctly.
As far as I can think, any solution we could come up with would involve user intervention somehow. There's just not a perfect solution for every server. If your solution works, then I'm glad you got it to work, and thanks for posting so that others might benefit.
But it's quite obvious that we've hit a defensive brick wall and I'm finished arguing the point. I have no doubt that the issue will ultimately be resolved as a matter of necessity in the longer run.
Until then, I'll leave you with my regards and best wishes
Richard Virtue
Regardless, thank you again for posting in case someone else benefits from your solution.
Zenphoto will ascertain the security level of your install from the permissions of the zp-core folder. On most well behaved servers that will be reported as 755, secure permissions from Zenphoto's viewpoint. Zenphoto will apply that permission to folders and mask it to turn off the execute bit for files. Thus a normal installation will have permissions of 755 for folders and 644 for files.
That yours was different is due either to an action you took or to something obscene that your server is doing.
But also note that there are a large number of installations that are not setup up properly to put Zenphoto in the "owner's" group. For these, the other groups must have their permissions relaxed in order to run.
Certainly this has been the situation for most of the security issues we have had reported.
I do understand that setting 777/666 permissions on all of Zenphoto's zp-core folders and files is NOT RECOMMENDED by you, or by me, or by anyone else with any intelligence. That is certainly NOT what I am wanting or trying to do, but that's what is happening during Zenphoto's set-up process, unlike any other web application set-up process I've ever used.
The central point I was making is that SUexec doesn't want that either and, in fact, will not allow it. Not only does SUexec NOT "force" Zenphoto to set such ridiculous permissions, it actually halts the entire process immediately as soon as 777/666 permission are set on those PHP folders and files. In other words, far from requiring those permissions, SUexec actually prohibits them and will not allow ANY process to continue after they are set on the PHP folders and files that are being used.
Your colleague claims that "it has nothing to do with Zenphoto" because the Zenphoto "setup script provides sane defaults" and that it "attempts to ensure that Zenphoto's files are secure." Maybe so, but the only default chmod that I can see is the following:
if (!defined('CHMOD_VALUE')) { define('CHMOD_VALUE', 0777); }
It would be difficult to get much LESS secure than that.
I want to be very clear that I think Zenphoto's PHP coding is generally superb and I like the application very much. In trying to avoid any need for any controlling intervention whatever by the user in its set-up, however, I think it may be just a little too "smart" for its own good.
In conclusion, assuming that ordinary folks on shared hosting services form any part of your target group, you're not going to be able to ignore the growing presence of SUexec amongst those services for long. My own hosts (Hostgator/The Planet) are generally regarded as NA industry leaders with excellent mod_security rules for the protection of all concerned. For your own sake (as well as for folks like me) I can only hope you'll be able find some way to accommodate the trend.
First, that default value really is what works most of the time on most servers. I know you do not think that so, but then you have not been answering the questions of users for the last two years whose systems fail when that is not the setting.
That code you refer to should be read literally--it says that if the CHMOD_VALUE is not defined it should be set to 0777--the value that has proved to work for the most people most of the time. If the value is otherwise defined then it stays what it was defined to. Probably not a "too smart for its own good" action". If you are going to be a "code reader" then you will really need to read and UDERSTAND all the code.
Second, that value has not been the default for quite a while, so you are using an older version, modified version, or some other of the zp-config.php file. Or you have selected that setting in the setup.
Perhaps you did not read my post above. I will reiterate. The default value for CHMOD is determined from the existing file permissions. Specifically from the permissions of the setup.php script folder. The value can be overridden by zp-config.php file, so if the define is set there to 0777 we have to believe that is what the user intended. If the permissions of the setup script are less strict than your server requires I really do not know how you would have got it to execute in the first place.
So, MY conclusion is that one of several things has happened with your installation.
And, yes, I do know that "if (!defined ...)" provides a default. That's what I said. I also said above that I had tried to override that default by instructing the setup to use normal (755/644) permissions, but it ignored that instruction and used its "default" for all of zp-core anyhow.
Anyhow, I now regret that "one more try" communication effort. Sorry about that. I promise not to bother you again.
If you insist on being ignorant, so be it.
It does add some information that was not obvious here from your somewhat derogatory and arrogant posting here. That you have been running versions of Zenphoto for some time and have not followed the recommendations on security that were in effect during those times.
Those are to whit:
Initially you changed security by editing the zp-config.php file to insert your CHMOD define. (This was how most Zenphoto configuration parameters were originally handled.) Clearly you did not do that or the value would have been defined and your edit of the functions.php file would have been irrelevant.
As the product advanced we have moved much of the configuration into the setup program or the Admin options. One of the things we did was place a warning on the assumed permissions settings in the setup process and the ability to change them to what worked better on your installation. Clearly you also ignored the warning or again the zp-config.php file would have included a define of the CHMOD and again your change would have been irrelevant.
So, in short, you have a zp-config.php file which is telling zenphoto that you wish to use the default which was in effect when you first installed. You have been notified that it may not be the best choice and you have ignored that notification.
I did run the update with lowest permissons possible und steped into the trouble.
Maybe you first run with loose chmod 755 and the with a ftp tool change some of the files to a lower permission 6xx
When I run the script again and again I could not change the permissions again -- the javascripot did not work at the "more information" link...
Gave me some trouble for 2 hours - now all looks fine again.
Anyway, I love ZP !
m.