Wiki hosting at SourceForge via MySQL database + php scripts



Hello James,

This message rehashes some issues that I may have already written
about in other contexts, but I'll try to collect everything here.

you wrote:

> I'm sorry I let this message get lost when I was going through the
> mail I missed while I was gone. If you are interested in setting
> up a Wiki at the Maxima Sourceforge site, I would be more than
> glad to have you do it.

And I would be happy to do so. There are two actions that need to
be taken -- (1) request a MySQL database from SF, and (2) install
wiki software in the Maxima web directory. A project administrator
needs to do (1), and any project developer can do (2). If you add
me as a developer, I can do (2) but you will need to carry out (1).
There is a link on the "admin" page for each SF project for 
"Shell/DB/Web", and on that page there is a "Manage Project Databases"
link. On that page there is a way to request a database and also
to set its password.

I looked around for wiki software and the one that seemed most
suitable is PhpWiki (http://sf.net/projects/phpwiki). This is 
installed from a tar file into the project web directory. 

> On Mon, 2003-12-22 at 16:56, Robert Dodier wrote:
> 
> > There are some security issues about this set up.
> > I'd be happy to talk about that if someone is interested.
> 
> I would, however, like to hear the security issues.

There are two kinds of issues: (1) vandalism of wiki pages, and
(2) comprising the MySQL db. For (1) it's not clear how much we
can/want to do. A wiki is a useful way to gather input from
many people, but then anyone can clobber some text or paste in
nonsense. Restricting access makes it harder to vandalize, and
also makes legitimate input harder.

About (2), a feature/bug of MySQL is that the db password must
appear in the script (Php, Perl, etc) which accesses the db.
So there is one PhpWiki file (index.php) which does contain the 
MySQL password. Since SF is a shared system, anyone with a shell
login could potentially try to access that file.

To address (1), PhpWiki (& other wiki s/w) supports capturing 
snapshots of all wiki pages in a zip file and also restoring
from a zip file. Also a page history is kept. PhpWiki appears
to supports user authentication (name & password) although 
user authentication is still under development -- accepting
external authentication seems to be the main topic.

About (2) -- index.php must be readable by the SF web server,
which runs as "nfsnobody". We can get SF admins to chown index.php
to nfsnobody, and then chmod it so that ordinary users can't
read it. However another user's broken/malicious web script 
(also running as nfsnobody) could conceivably access index.php,
so chgrp/chmod is not airtight. Better still would be to run
the web server with chroot but that is beyond our control.

If the wiki db were compromised (say by someone who obtains
the MySQL password), clearly the wiki would be messed up but
I don't know a mechanism by which this would expose the 
bug tracker and other SF resources. I asked just that question
on the PhpWiki mailing list and I got one response, which
said that knowing the MySQL password would only be helpful to
an attacker if the bug db, etc., were controlled by the same
password. I don't think they are.

Overall I think PhpWiki at SF would be workable. I can try
to resolve any further questions that arise.

regards,
Robert Dodier

__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus