[dokuwiki] Re: Locking down a dokuwiki install

I actually sent in a patch to do a very limited read-only server just
recently. Hadn't taken it nearly as far as you have, but that seems like
a good idea.

In our case, I'm using it to provide a failover server in conjunction
with IPVS/LVS/Keepalived. I want the failover server to be read-only
though. Seems like your stuff would be a good idea to combine with the
patch I have.

I just added two config options "readonly" and "readonlymsg". That makes
it real easy to just check against $conf['readonly'] throughout the
code. The msg (if set) is displayed in the msg bar. This is appropriate
for our failover server, but in your case, probably would be best left
blank.

-- Nathan
 
------------------------------------------------------------
Nathan Neulinger                       EMail:  nneul@xxxxxxx
University of Missouri - Rolla         Phone: (573) 341-6679
UMR Information Technology             Fax: (573) 341-4216
 

> -----Original Message-----
> From: dokuwiki-bounce@xxxxxxxxxxxxx 
> [mailto:dokuwiki-bounce@xxxxxxxxxxxxx] On Behalf Of Mark McCoy
> Sent: Monday, January 30, 2006 9:22 AM
> To: dokuwiki@xxxxxxxxxxxxx
> Subject: [dokuwiki] Locking down a dokuwiki install
> 
> Hey all,  I was wondering if I could get some
> thoughts/ideas/suggestions on creating a "read-only" instance of
> dokuwiki.
> 
> I've used dokuwiki for about a year for my personal uses, and I've
> implemented a dokuwiki for our internal use in my group at work. 
> Everyone loves it, and it is so much easier to use than our old
> (basically non-existant) method of pooling our information and
> resources.
> 
> I've been tasked with updating a server which will primarily serve up
> documentation/help/FAQ type info to our students (this is a University
> setting) about how to use our webmail and how to create/upload web
> pages onto the student web server.  The information is very old,
> hasn't been updated in years, and combine a lot of home-grown perl and
> html pages that are incoherent and have about 3 different interfaces
> that all look like somebody's vanity page from 1993.  My boss loves
> the idea of using dokuwiki to replace all of this, and I've got a
> template made up that mimics our main Univesity web page.
> 
> Uni is unique in that it is not just the outside world we have to
> defend against, but our customers (students) as well!  So I'm
> implementing a dokuwiki that is as "locked-down" as can be.   I've
> done the following to make this instance of doku absolutely read-only:
> 
> 1. turned on ACL's, and used just one rule >> *  @ALL 1
> 2. empty user.auth.php
> 3. edited doku.php and commented out the lines that respond to the
> "?do=" HTTP_REQUEST and the doku http header (lines 23 and 40 in the
> 2005-09-22 source).  This ensures that the users can't go to any
> edit/admin/etc... any of the pages.
> 4. using system-level file permissions to make the data pages
> read-only for web server uid/gid
> 
> I know we're being paranoid, but that is the environment we are in ;)
> 
> We have another instance of doku on an internal machine that will be
> used to actually edit and keep rev history of the pages, and we will
> rsync that data to the "published" version.
> 
> So, does this sound reasonable, and are there any gotchas/pitfalls
> that I may have missed along the way?
> 
> 
> --
> Mark McCoy -- Professional Unix geek
> 
> "On two occasions I have been asked, 'Pray, Mr. Babbage, if you put
> into the machine wrong figures, will the right answers come out?' I am
> not able rightly to apprehend the kind of confusion of ideas that
> could provoke such a question. "  -- Charles Babbage
> -- 
> DokuWiki mailing list - more info at
> http://wiki.splitbrain.org/wiki:mailinglist
> 
> 
--
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist

Other related posts: