web commit by http://ccshan.myopenid.com/

[ikiwiki.git] / doc / patchqueue / various_fixes.mdwn

diff --git a/doc/patchqueue/various_fixes.mdwn b/doc/patchqueue/various_fixes.mdwn
index 9ffd17b30427a3d17d459b47ab7d021c3a353909..318e7e941c7c7d5b1eb04ae769296786d543bbf7 100644 (file)
--- a/doc/patchqueue/various_fixes.mdwn
+++ b/doc/patchqueue/various_fixes.mdwn
@@ -31,6 +31,26 @@ are trying to do, and it still works here as I use a similar LANG anyway.
 For reference svn version 1.3.1 (r19032), my $LANG=en_GB.utf8, but I'm not 
 sure what the CGI was running under. 
 
 For reference svn version 1.3.1 (r19032), my $LANG=en_GB.utf8, but I'm not 
 sure what the CGI was running under. 
 

+> That's strange. Is the problem to do with setting LANG=C or to do
+> with the way it's set and exported on the same line as the svn info call?
+> Can you reproduce the problem running svn info outside of ikiwiki?
+> --[[Joey]]
+
+>> I've now managed to reproduce the problem. I'll try and give some more information.
+>> When going to the Recent Changes link I get 
+
+    [Sat Sep 16 15:16:08 2006] [error] [client xxxx] svn: Can't check path '/home/jw2328/.subversion': Permission denied, referer: http://xxxxx/test/sandbox.html
+    [Sat Sep 16 15:16:08 2006] [error] [client xxxx] Use of uninitialized value in concatenation (.) or string at /usr/lib/perl5/site_perl/5.8.3/IkiWiki/Rcs/svn.pm line 145., referer: http://xxxx/test/sandbox.html
+    [Sat Sep 16 15:16:08 2006] [error] [client xxxxx] svn: Can't check path '/home/jw2328/.subversion': Permission denied, referer: http://xxxx/test/sandbox.html
+    [Sat Sep 16 15:16:09 2006] [error] [client xxxx] File does not exist:  at /usr/lib/perl5/site_perl/5.8.3/IkiWiki/Rcs/svn.pm line 145, referer: http://xxxx/test/sandbox.html
+    [Sat Sep 16 15:16:09 2006] [error] [client xxxx] Premature end of script headers: ikitest, referer: http://xxxx/test/sandbox.html
+
+>> which the $svn_url is causing the uninitialised value, due to the 
+>> LANG=C it seems, as if I remove it it goes away.
+>> The file does not exist is due to the unreadable .subversion.
+>> echoing the LANG before it is set shows that the variable is normally 
+>> empty for the user that is running it.
+

 The second removes problems with cannot access /home/$user/.svnsomething in
 the logs. I think this problem was also fatal (I should have reported these
 sooner). 
 The second removes problems with cannot access /home/$user/.svnsomething in
 the logs. I think this problem was also fatal (I should have reported these
 sooner). 


@@ -39,21 +59,35 @@ I can try and debug these problems if you could suggest some way to do so,
 but I am probably losing the server in a couple of days, so I can't be of too
 much help I'm afraid.
 
 but I am probably losing the server in a couple of days, so I can't be of too
 much help I'm afraid.
 

-    --- IkiWiki/Plugin/search.pm
-    +++ IkiWiki/Plugin/search.pm
-    @@ -99,7 +99,7 @@
-            close TEMPLATE;
-            $cgi="$estdir/".IkiWiki::basename($config{cgiurl});
-            unlink($cgi);
-    -       symlink("/usr/lib/estraier/estseek.cgi", $cgi) ||
-    +       symlink("/usr/local/libexec/estseek.cgi", $cgi) ||
-                    error("symlink $cgi: $!");
-     } # }}}
-
-obviously I'm not asking you to include this patch, but it would
-be good if this sort of thing was configurable (at build time?). I can
-have a go if you like, but I'm not sure what would be acceptable to
-you.
+> I imagine that passing --config-dir /tmp would be either insecure or 
+> would limit ikiwiki use to one user per machine. 
+> `--config-dir /etc/subversion` might be better, though still a hack,
+> since a user's real ~/.subversion might be needed to access some repos.
+> 
+> Maybe I didn't notice this problem since I have a ~/.subversion
+> everywhere that I've used ikiwiki. Hmm, no, I don't reproduce it, svn
+> happily recreated the directory during an ikiwiki run after I moved it
+> out of the way here. Maybe an issue with old versions of svn? Although
+> AFIACR, svn has auto-created ~/.subversion for years.
+> 
+> What's the error message? --[[Joey]]
+
+>> `svn: Can't check path '/home/jw2328/.subversion': Permission denied,`
+>> where jw2328 is my usual user. 
+>> I have restrictive permissions of 0700 on home dirs on the server,
+>> and the CGI is running as uid apache, euid root. (Not my setup anymore).
+>> The way I had it set up, was jw2328 owning thesource dir, and the svn repo,
+>> with g+sw on them both. I ran sudo ikiwiki --setup though, as I was reluctant
+>> to adjust permissions on my cgi-dir. This seems to be the root of the 
+>> problem.
+
+>>> Ah, I think it's better to keep the permissions of the repository
+>>> and source directory sane (755) and make the cgi suid to your user,
+>>> which is how it's designed to work.
+
+>>>> I realise that now, and I now have a much more sane setup that works.
+
+----

 
     --- IkiWiki.pm
     +++ IkiWiki.pm
 
     --- IkiWiki.pm
     +++ IkiWiki.pm


@@ -84,21 +118,55 @@ values become tainted from nowhere, or they don't get untainted possibly.
 This also affects backports to sarge. `"oh"` is not going to be very 
 informative if that code path is ever taken, but I hope that it never is.
 
 This also affects backports to sarge. `"oh"` is not going to be very 
 informative if that code path is ever taken, but I hope that it never is.
 

-As for backports there is a problem with the sarge version of libcgi-session-perl
-and my sslcookie patch (complaints about a missing include file auto/CGI/Session/cookie.al IIRC).
-This file does not and has not ever existed, but it appears to be fixed in 
-the backport of libcgi-session-perl that I did. That puts the dependency
-required at somewhere between 3.95-2 and 4.14-1. This could then be added
-to debian/control. It would mean one more package to backport, but stops the
-bug if anyone actually uses my sslcookie option except me.
+> You're not the first person to report a problem here with older versions 
+> of perl and pagespec tainting. I suspect that this would work around it:
+       return eval possibly_foolish_untaint(pagespec_translate($spec));
+> I'm _very_ uncomfortable putting that in the shipping version of ikiwiki,
+> because pagespecs are potentially _insanely_ dangerous, given how they're
+> evaled and all. The tainting is the only sanity check there is that
+> `pagespec_translate` manages to clean up any possibly harmful perl code
+> in a pagespec. It's good to have belt and suspenders here. 
+> 
+> For all I know, older versions of perl are keeping it tainted because
+> `pagespec_translate` is somehow broken under old versions of perl and is
+> in fact not fully untainting the pagespec. Ok, probably not, it's more
+> likely that some of the regexps in there don't manage to clear the taint
+> flag with old versions of perl, while still doing a perfectly ok job of
+> sanitising the pagespec.
+> 
+> I suppose that the version of perl ($^V) could be checked and the untaint 
+> only be called for the old version. Though it seems it would be better
+> to try to debug this some first. Maybe instrumenting `pagespec_translate`
+> with calls to Scalar::Utils's tainted() function and seeing which parts
+> of pagespecs arn't getting untainted would be a good start.
+> 
+> --[[Joey]]
+
+>> It seems like it is always the (with instrumentation)
+     
+     elsif ($word =~ /^(link|backlink|created_before|created_after|creation_month|creation_year|creation_day)\((.+)\)$/) {
+          warn("\$1 tainted=".tainted($1).", \$2 tainted=".tainted($2)." \$code tainted=".tainted($code));
+          $code.=" match_$1(\$page, ".safequote($2).")";
+          warn("\$1 tainted=".tainted($1).", \$2 tainted=".tainted($2)." \$code tainted=".tainted($code));
+          warn("safequote tainted=".tainted(safequote($2)));
+     }
+
+>> bit that causes it. With the following trace:

 
 

-As for backports I managed with 
+     $1 tainted=0, $2 tainted=0 $code tainted=0 at IkiWiki.pm line 718.
+     $1 tainted=0, $2 tainted=0 $code tainted=1 at IkiWiki.pm line 720.
+     safequote tainted=0 at IkiWiki.pm line 721.

 
 

- * ikiwiki_1.26
- * libcgi-formbuilder-perl_3.03.01-1
- * libcgi-session-perl_4.14-1
+>> which shows that `$code` appears to become tainted from nowhere.
+>> <http://mail-archives.apache.org/mod_mbox/spamassassin-dev/200509.mbox/%3C3838.431C7D9B.5F152B8F.dev@spamassassin.apache.org%3E>
+>> is what pointed me to find the problem/workaround.

 
 

-backported to sarge, with bpo in sources.list. This only covers Depends: though,
-for instance hyperestraier needs to be backported, which I haven't got
-round to yet as there is a chain to do.
+>>> Given that verification, an untaint contingent on the value of $^V
+>>> sounds reasonable and I'd accept such a patch. I'm not quite sure which
+>>> version(s) of perl it should check for.

 
 

+>>>> I'm not going to write one though. I don't know what versions either,
+>>>> but I think the evil of the special case is too much in this case. If
+>>>> you are happy to insist on a newer version of perl then I will leave 
+>>>> it at that and sort something out locally. If you want the patch I will 
+>>>> code it though, as I realise you may want to support sarge installs.