git.oblomov.eu Git - ikiwiki/blob - doc/patchqueue/various_fixes.mdwn

   1 Sorry if you don't appreciate me lumping all of these patches together.
   2
   3 These are various fixes I had to make when installing Ikiwiki. Some are
   4 due it being a non-Debian system, the others are actual bugs.
   5
   6     --- upstream/IkiWiki/Rcs/svn.pm 2006-09-16 01:11:55.000000000 +0100
   7     +++ main/IkiWiki/Rcs/svn.pm     2006-09-16 01:12:50.000000000 +0100
   8     @@ -34,7 +34,7 @@
   9             my $field=shift;
  10             my $file=shift;
  11
  12     -       my $info=`LANG=C svn info $file`;
  13     +       my $info=`svn info $file`;
  14             my ($ret)=$info=~/^$field: (.*)$/m;
  15             return $ret;
  16      } #}}}
  17     @@ -140,7 +140,7 @@
  18                     if $svn_version =~ /\d\.(\d)\.\d/ && $1 >= 2;
  19
  20             my $svn_url=svn_info("URL", $config{srcdir});
  21     -       my $xml = XMLin(scalar `svn $svn_limit --xml -v log '$svn_url'`,
  22     +       my $xml = XMLin(scalar `svn $svn_limit --xml -v log '$svn_url' --config-dir /tmp`,
  23                     ForceArray => [ 'logentry', 'path' ],
  24                     GroupTags => { paths => 'path' },
  25                     KeyAttr => { path => 'content' },
  26
  27 The first hunk of this patch is strange. It just failed to work with this
  28 in place, and it took me a long time to figure it out. I realise what you
  29 are trying to do, and it still works here as I use a similar LANG anyway.
  30
  31 For reference svn version 1.3.1 (r19032), my $LANG=en_GB.utf8, but I'm not
  32 sure what the CGI was running under.
  33
  34 > That's strange. Is the problem to do with setting LANG=C or to do
  35 > with the way it's set and exported on the same line as the svn info call?
  36 > Can you reproduce the problem running svn info outside of ikiwiki?
  37 > --[[Joey]]
  38
  39 >> I've now managed to reproduce the problem. I'll try and give some more information.
  40 >> When going to the Recent Changes link I get
  41
  42     [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
  43     [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
  44     [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
  45     [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
  46     [Sat Sep 16 15:16:09 2006] [error] [client xxxx] Premature end of script headers: ikitest, referer: http://xxxx/test/sandbox.html
  47
  48 >> which the $svn_url is causing the uninitialised value, due to the
  49 >> LANG=C it seems, as if I remove it it goes away.
  50 >> The file does not exist is due to the unreadable .subversion.
  51 >> echoing the LANG before it is set shows that the variable is normally
  52 >> empty for the user that is running it.
  53
  54 The second removes problems with cannot access /home/$user/.svnsomething in
  55 the logs. I think this problem was also fatal (I should have reported these
  56 sooner).
  57
  58 I can try and debug these problems if you could suggest some way to do so,
  59 but I am probably losing the server in a couple of days, so I can't be of too
  60 much help I'm afraid.
  61
  62 > I imagine that passing --config-dir /tmp would be either insecure or
  63 > would limit ikiwiki use to one user per machine.
  64 > `--config-dir /etc/subversion` might be better, though still a hack,
  65 > since a user's real ~/.subversion might be needed to access some repos.
  66 >
  67 > Maybe I didn't notice this problem since I have a ~/.subversion
  68 > everywhere that I've used ikiwiki. Hmm, no, I don't reproduce it, svn
  69 > happily recreated the directory during an ikiwiki run after I moved it
  70 > out of the way here. Maybe an issue with old versions of svn? Although
  71 > AFIACR, svn has auto-created ~/.subversion for years.
  72 >
  73 > What's the error message? --[[Joey]]
  74
  75 >> `svn: Can't check path '/home/jw2328/.subversion': Permission denied,`
  76 >> where jw2328 is my usual user.
  77 >> I have restrictive permissions of 0700 on home dirs on the server,
  78 >> and the CGI is running as uid apache, euid root. (Not my setup anymore).
  79 >> The way I had it set up, was jw2328 owning thesource dir, and the svn repo,
  80 >> with g+sw on them both. I ran sudo ikiwiki --setup though, as I was reluctant
  81 >> to adjust permissions on my cgi-dir. This seems to be the root of the
  82 >> problem.
  83
  84 >>> Ah, I think it's better to keep the permissions of the repository
  85 >>> and source directory sane (755) and make the cgi suid to your user,
  86 >>> which is how it's designed to work.
  87
  88 >>>> I realise that now, and I now have a much more sane setup that works.
  89
  90 ----
  91
  92     --- IkiWiki.pm
  93     +++ IkiWiki.pm
  94     @@ -734,7 +734,18 @@
  95             my $page=shift;
  96             my $spec=shift;
  97
  98     -       return eval pagespec_translate($spec);
  99     +        my $pagespec = pagespec_translate($spec);
 100     +
 101     +        my $newpagespec;
 102     +
 103     +       local($1);
 104     +       if ($pagespec =~ /(.*)/) {
 105     +               $newpagespec = $1;
 106     +       } else {
 107     +               die "oh";
 108     +       }
 109     +
 110     +       return eval $newpagespec;
 111      } #}}}
 112
 113      sub match_glob ($$) { #{{{
 114
 115 This works around a silly, but extremely annoying, taint bug in older
 116 versions of perl. I'm not sure of the details, but it means that either
 117 values become tainted from nowhere, or they don't get untainted possibly.
 118 This also affects backports to sarge. `"oh"` is not going to be very
 119 informative if that code path is ever taken, but I hope that it never is.
 120
 121 > You're not the first person to report a problem here with older versions
 122 > of perl and pagespec tainting. I suspect that this would work around it:
 123         return eval possibly_foolish_untaint(pagespec_translate($spec));
 124 > I'm _very_ uncomfortable putting that in the shipping version of ikiwiki,
 125 > because pagespecs are potentially _insanely_ dangerous, given how they're
 126 > evaled and all. The tainting is the only sanity check there is that
 127 > `pagespec_translate` manages to clean up any possibly harmful perl code
 128 > in a pagespec. It's good to have belt and suspenders here.
 129 >
 130 > For all I know, older versions of perl are keeping it tainted because
 131 > `pagespec_translate` is somehow broken under old versions of perl and is
 132 > in fact not fully untainting the pagespec. Ok, probably not, it's more
 133 > likely that some of the regexps in there don't manage to clear the taint
 134 > flag with old versions of perl, while still doing a perfectly ok job of
 135 > sanitising the pagespec.
 136 >
 137 > I suppose that the version of perl ($^V) could be checked and the untaint
 138 > only be called for the old version. Though it seems it would be better
 139 > to try to debug this some first. Maybe instrumenting `pagespec_translate`
 140 > with calls to Scalar::Utils's tainted() function and seeing which parts
 141 > of pagespecs arn't getting untainted would be a good start.
 142 >
 143 > --[[Joey]]
 144
 145 >> It seems like it is always the (with instrumentation)
 146
 147      elsif ($word =~ /^(link|backlink|created_before|created_after|creation_month|creation_year|creation_day)\((.+)\)$/) {
 148           warn("\$1 tainted=".tainted($1).", \$2 tainted=".tainted($2)." \$code tainted=".tainted($code));
 149           $code.=" match_$1(\$page, ".safequote($2).")";
 150           warn("\$1 tainted=".tainted($1).", \$2 tainted=".tainted($2)." \$code tainted=".tainted($code));
 151           warn("safequote tainted=".tainted(safequote($2)));
 152      }
 153
 154 >> bit that causes it. With the following trace:
 155
 156      $1 tainted=0, $2 tainted=0 $code tainted=0 at IkiWiki.pm line 718.
 157      $1 tainted=0, $2 tainted=0 $code tainted=1 at IkiWiki.pm line 720.
 158      safequote tainted=0 at IkiWiki.pm line 721.
 159
 160 >> which shows that `$code` appears to become tainted from nowhere.
 161 >> <http://mail-archives.apache.org/mod_mbox/spamassassin-dev/200509.mbox/%3C3838.431C7D9B.5F152B8F.dev@spamassassin.apache.org%3E>
 162 >> is what pointed me to find the problem/workaround.
 163
 164 >>> Given that verification, an untaint contingent on the value of $^V
 165 >>> sounds reasonable and I'd accept such a patch. I'm not quite sure which
 166 >>> version(s) of perl it should check for.
 167
 168 >>>> I'm not going to write one though. I don't know what versions either,
 169 >>>> but I think the evil of the special case is too much in this case. If
 170 >>>> you are happy to insist on a newer version of perl then I will leave
 171 >>>> it at that and sort something out locally. If you want the patch I will
 172 >>>> code it though, as I realise you may want to support sarge installs.