[pmwiki-users] PmWiki work directory

HaganFox haganfox at users.sourceforge.net
Fri Dec 22 01:22:10 CST 2006


Patrick R. Michaud <pmichaud <at> pobox.com> writes:
> 
> On Wed, Dec 20, 2006 at 12:30:13AM +0100, christian.ridderstrom <at> gmail.com
wrote:
> > On Tue, 19 Dec 2006, Patrick R. Michaud wrote:
[...]
> > >Downsides:
> > >  - it's another (webserver writable) directory to keep track of
> > >  - for sites that have been moving wiki.d/ out of the pmwiki root,
> > >    this directory has to be moved also
> > >  - the work.d/ directory has to be protected somehow (just like
> > >    wiki.d/ does)
> > 
> > Could we have a writable directory called pmwiki.d/, which in turns by 
> > default contains wiki.d/ and work.d/. (Possibly even uploads?)
> 
> Having a separate writable directory for writable data makes sense.

It certainly does.

[The following is incomplete.  I'm just brainstorming here while attempting to
be brief.]

I proposed or at least discussed this a long time ago but I can't seem to locate
or access the thread(s) in the archives.  (The pmichaud.com domain is not
resolving for me tonight.)

> The difficult part is deciding what to do with uploads/ -- on the one
> hand, it makes sense that uploads/ would go where other writable
> directories go, but on another hand it makes url processing a bit
> more difficult.  Thoughts?

A case could be made for treating uploads/ differently since it's the only
web-accessible writable directory (by default, anyway).

General thoughts:

Without a doubt having a single directory be the top of the "writable tree"
would have been better from the beginning.  Now that I'm accustomed to the
current directory layout it doesn't seem as compelling.

Single writable-tree advantages:

1) It's easy to understand.  Fewer directories in the main directory makes it
clearer what each one is for.

2) Installation is easier and more goof-proof.

2a) Safe Mode not withstanding, you could just change the permissions on one
directory (which might even come with the distribution) to 777 and be done.

2b) The slightly-more-secure method would not require setting permissions on the
main directory, reducing the chance of leaving the main directory writable.[1]

2c) Under some hosted-environment scenarios, setting 2777 permissions on the
main directory is not possible.  (Yes, there are workarounds.)[2]

3) Backup and restore procedures could be simplified.[3]  Same goes for
"permissions repair".[4]

4) It would be easier to move the writable directories outside the web document
tree.  Just move one directory and add/change one or two configuration settings.

Hagan

[1] A proposed solution for this was a "security audit" script that would check
permissions and report writable directories/files that don't need to be writable.

[2] For many mew administrators installing PmWiki in the webroot is easier to
understand compared to using chdir() in a wrapper script.  There are other
benefits, such as the path to pub/ being just http://FQDN/pub/, not
http://FQDN/pmwiki/pub/.

[3] As it is now, restoring a wiki is not straightforward, especially if there
are uploads.  The reason is because PmWiki needs to create directories and when
you untar an archive those directories have the wrong permissions.  See the next
note...

[4] I can envision permissions repair being a relatively simple matter.
* Rename the main writable directory.
* Create a new main writable directory and set its permissions.
* PmWiki duplicates the tree structure in the new writable tree.
* The administrator moves the files over to the new tree.  (Copy-then-delete
might work better, where PmWiki might even do the copying.)






More information about the pmwiki-users mailing list