01101: passwdattr and passwdedit in files in wikilib.d folder breaks them (Server Error 500)
Description: For some time now I encountered a "500 Internal Server Error" accompanied by the beloved "Premature end of script headers"-log file entry whenever I wanted to view some pages in my PmWiki-installation. The most important of them was "PmWiki/DocumentationIndex". I contacted my Hosting Service, tried setting permissions, reconfigured PmWiki, reinstalled PmWiki and all the usual stuff until I finally figured it out.
The problem is caused by the lines "passwdattr=*some_hash*" and "passwdedit=*some_hash*"
in some files inside the wikilib.d folder, which are included in the DocumentationIndex via {AuthUser$:Summary}. The files I tracked down are "Initial setup tasks", "AuthUser" and "Mailing lists" (there are possibly more).
These two lines somehow break some script, witch exits silently (due to some build in access violation?) and these pages (and any pages which include them) can't be displayed (Error 500...). I manually removed them and now anything works fine. I don't know if they are needed in the documentation shipped with PmWiki and imagine they are left over from edits to this site here. I would like to either get the underlying issue fixed or see them striped out the next release.
Thank you
This means that you probably cannot set any password on any page or WikiGroup. Or can you? Is there a 500 error when you access directly such a page (read, edit, history...)? Some pages in the default installation may be semi-protected if they have been subject to vandalism on pmwiki.org. There is also the SiteAdmin group which is locked both for reading and editing, and the Site group which is read-only. --Petko June 27, 2009, at 02:32 AM
I tried what you asked:
Setting passwords works as expected on single pages and on a WikiGroup.
By "read" you mean the normal display by going to the site using the URL without any additional parameters, right?
For pages which include a page which has the pages which have "passwdattr=*some_hash*" can't be read, but can be edited and display the history, if I manually add ?action=edit / ?action=diff to the URL.
The pages which have "passwdattr=*some_hash*"/"passwdedit=*some_hash*" themselves can neither be read, edited or display the history.
"SiteAdmin/SiteAdmin", "SiteAdmin/AuthUser", "SiteAdmin/GroupAttributes" and "SiteAdmin/Status" work, "SiteAdmin/AuthList" breaks with error 500.
"Site/PageListTemplates" breaks, anything else in Site-Group works. I don't know why "SiteAdmin/AuthList" and "Site/PageListTemplates" break.
Hello. I suspect that your PHP installation might be missing some required function like crypt() but I see no way to check this. Can you open pmwiki.php?action=crypt on your wiki, and can you submit the form, and does it behave like on pmwiki.org? --Petko July 02, 2009, at 08:11 AM
Hi,
I suspect the output should be the similar on all PmWiki-Sites, right? The form works and doesn't fail visibly, but it creates a very different output.
I used "test" as input. On my installation one result is "K4t3y/ev31QBw", here it is "$1$MsqLeA4X$85gUQqSGn2FLMPqK92x8p0". Both are changing on every re-submit.
I checked the plain files and they show the same behavior. When I set a password on my site, it is like my short output above, but the passwords shipped with PmWiki's documentation are obviously like the long one.
If I manually insert some made up value like my short output in the passwdattr field it also fixes the 500 error for the page.
Is there anything in phpinfo() which could be useful?
Your PHP installation seems to use a different encryption algorithm, and it probably cannot decrypt passwords with the default one. I'll try to find some time to look into it further, but for the moment, here are all pages containing passwords:PmWiki.AuthUser PmWiki.InitialSetupTasks PmWiki.LinkVariables PmWiki.MailingLists Site.GroupAttributes Site.AuthUser Site.SideBar SiteAdmin.GroupAttributes
You may want to manually remove the passwd*=$1$HASH lines from the files. The lines passwd*=@lock and similar should be OK (please confirm). If the problem is not fixable, we might be able to strip those passwords from the default installation. Thanks! --Petko July 02, 2009, at 10:44 AM
passwd*=@lock and similar are indeed OK. I only had to remove the lines from the following pages:PmWiki.AuthUser PmWiki.InitialSetupTasks PmWiki.LinkVariables PmWiki.MailingLists
I also checked php.net about crypt() for a possible answer and I found the underlying problem!
I turns out php's internal "CRYPT_STD_DES"- and "CRYPT_BLOWFISH"-variables are 1, but only CRYPT_STD_DES is supported!
If you try to use the Blowfish-algorithm the script using it dies and you get the error 500.
It looks like this site and the default PmWiki-passwords defaults to MD5, which is not supported on my php-installation. crypt() or something in PmWiki then falls back to Standard_DES, which is why my setup creates these shorter hashes.
I think in some script PmWiki/crypt() tries to decode the MD5 hash in passwd*=$1$HASH using blowfish and blowfish breaks my php-installation.
From phpinfo() I can gather that the mcrypt-extension is installed, may be it could be involved in some sort of workaround.
However I am going to contact my hosting company (again) and try to get them to fix blowfish or at least set CRYPT_BLOWFISH to 0.
I don't know if there is anything which could be improved in PmWiki to avoid such situations, but it seems not to be its fault at all.
Thank you for your help. If you need any additional information I try to get it.
---
The "technical support" from my hosting company is confident that its a PHP-error, as they don't apply patches. They also say I have to buy a root-server, because I could change php/php-config if I want to. As I can't debug the server (to figure out if its PHP or the servers blowfish-backend) and don't need a root-server for my small site I have to rest this case.
PHP 5.3 implements crypt() itself which should solve this problem. If it gets adopted in the next 1 to 5 years by my hosting company I check again.
It would be nice if the passwd*=$1$HASH lines could be stripped out in the next release (Or someone could come up with some sort of workaround). Maybe other installations lacking MD5 capable crypt() have issues too.
Thank you again
I fixed the release building script to strip out those passwords. Next releases and SVN pre-releases should be fine. Thanks for your investigation and report. --Petko July 07, 2009, at 03:14 PM