added cgi support

2 files changed, 39 insertions, 4 deletions

diff --git a/doc/bugs.mdwn b/doc/bugs.mdwn
index 235f06fb7..e052763f1 100644
--- a/doc/bugs.mdwn
+++ b/doc/bugs.mdwn
@@ -4,3 +4,5 @@
   to point to it, but will forget to update the linkbacks in Foo/Baz.
   And if Foo/Bar/Baz is then removed, it forgets to update Foo/Bar to link
   back to Foo/Baz.
+* Foo/Bar/Baz shows up as Bar/Baz in the linkbacks on page Foo/Bar. Should
+  show as just Baz there.
diff --git a/doc/security.mdwn b/doc/security.mdwn
index d3e137588..7b056fd6c 100644
--- a/doc/security.mdwn
+++ b/doc/security.mdwn
@@ -1,9 +1,10 @@
 Let's do an ikiwiki security analysis..
 
-If you are using ikiwiki to render pages that only you can edit, then there
-are no more security issues with this program than with cat(1). If,
-however, you let others edit pages in your wiki, then some security issues
-do need to be kept in mind.
+If you are using ikiwiki to render pages that only you can edit, do not
+generate any wrappers, and do not use the cgi, then there are no more
+security issues with this program than with cat(1). If, however, you let
+others edit pages in your wiki, then some possible security issues do need
+to be kept in mind.
 
 ## html attacks
 
@@ -50,3 +51,35 @@ to the html pages, etc.
 If the wrapper script is made suid, then any bugs in this wrapper would be
 security holes. The wrapper is written as securely as I know how and
 there's been no problem yet.
+
+## symlink attacks
+
+Could a committer trick ikiwiki into following a symlink and operating on
+some other tree that it shouldn't? svn supports symlinks, so one can get
+into the repo. ikiwiki uses File::Find to traverse the repo, and does not
+tell it to follow symlinks, but it might be possible to race replacing a
+directory with a symlink and trick it into following.
+
+It would certianly be possible to start out with a directory, let ikiwiki
+run and find a file in there, then replace it with a symlink, and ikiwiki
+would then go ahead and follow the symlink when it went to open that file
+to read it. If it was some private file and was running suid, that could be
+bad.
+
+TODO: seems that locking to prevent more than one ikiwiki run at a time
+would both fix this and is a good idea in general. With locking, an
+attacker couldn't get ikiwiki to svn up while another instance was running.
+
+Even with locking, if an attacker has local write access to the checkout,
+they could still fool ikiwiki using similar races. So it's best if only one
+person can ever write to the checkout that ikiwiki compiles the moo from.
+
+## cgi security
+
+When ikiwiki runs as a cgi to edit a page, it is passed the name of the
+page to edit. It has to make sure to sanitise this page, to prevent eg,
+editing of ../../../foo, or editing of files that are not part of the wiki,
+such as subversion dotfiles. This is done by sanitising the filename
+removing unallowed characters, then making sure it doesn't start with "/"
+or contain ".." or "/.svn/". Annoyingly ad-hoc, this kind of code is where
+security holes breed.