[pmwiki-users] Host concerns
dausha at gmail.com
Thu Mar 29 11:18:44 CDT 2007
On 3/29/07, Dan Knight <lowenddan at gmail.com> wrote:
> I would like to use pmwiki for some in-house projects, but my host is
> concerned about write permissions and runaway processes:
> "Is there a way it can run without having the webserver writing files to
> your directory? Or is that impossible? I just hate to give the web server
> any sort of ability to do that, for fear of runaway processes filling up the
> drive, etc."
> How do I answer him?
I'm not sure if this is a commercial web host provider, or your
employer's web administrator, but "in-house" leads me to deduce the
latter. If the former is the case, I wouldn't worry about persuading
the web host provider. I would move to find a more friendly provider,
which are legion. Web hosting is a commodity product.
I'll bet the runaway process issues is less significant than the write
permission for the web server. Pm clearly explained that runaway
processes is essentially a non-issue as such a condition is
anticipated and controlled via php.ini (i.e., 30 second rule).
However, a skittish admin would be wary of allowing write permissions,
mostly because of presumed ability to use that ability to write
malicious scripts and hack the server. I'm sure Pm could elaborate on
this, but PmWiki anticipates and controls this problem.
IIRC, PmWiki ensures that permissions for any file written by its
system is chmoded to 666; which ensures the file cannot be executed.
This prevents uploading a script then running it.
IIRC, PmWiki uses .htaccess to prevent direct browser access to
wiki.d, one of only two directories writable by PmWiki (the other
being upload.d, but only when activated explicitly).
Finally, PmWiki does not execute code in a page by default; although
some recipes may allow code execution. So, while a page may contain
malicious code, PmWiki won't run it.
Patrick zealously corrects any security issues with PmWiki itself. Any
problems with the kernel, PHP, or Apache are naturally beyond his
control; but should not be an excuse given by a paranoid system
administrator to bar use of PmWiki as they fall within the
If the skittish admin's concern is about PmWiki being used to bomb a
hard drive, then he needs to impose a quota on the web server, have a
separate script to monitor usage, or buy a bigger hard drive. Email
bombing is the preferred means of attack when it comes to this sort of
Best way to answer him is to find his exact concern and to demonstrate
(perhaps via the PmWiki site or a direct, private email from Pm or
somebody else) that his concerns are mitigated. We're left guessing
the precise reason for his concern, but I think most the real concerns
have been addressed in this email and by the others.
"Words are the only thing which will last forever" Churchill
More information about the pmwiki-users