Thursday, October 23 2003

Some background :

1. I like CGI::Kwiki.
2. The target machine uses cgiwrap and not suExec (for a variety of good reasons.)
3. cgiwrap doesn't DWIM when it comes to .htaccess files. This is understandable and not at all surprising when you stop to think about it.
4. As such, the only way to create a secure and authenticated Kwiki is to :
   1. Create a special kwiki user with restricted permissions.
   2. Create a special Directory directive in your Apache config file with the requisite options for enabling CGI scripts and doing authentication.
   3. Remove all world readable and writable (eek!) permissions from the Kwiki config files and databases
   4. Change the ownership on the Kwiki CGI scripts to your kwiki user and enable to setuid bit (so the program can read and modify the databases.)
5. Almost every CGI::Kwiki related package calls Perl's built-in glob function which, rightly, causes setuid Perl scripts to chuck a spaz complaining about insecure dependencies .

Now, you may think that the kinds of anal-retentive security concerns outlined above are somehow antithetical to the Idea of Wiki and all its crunchy sharing and open editing. That's your business.

There are, however, instances when you may want to use the basic Wiki framework in a restricted environment for managing content that is not meant to be universally accessible. You should be able to do this. Otherwise, if you and I share the same web host, either one of us could simply write a CGI program, run as user http , to read, or write, the raw databases even though we might have insufficient permissions to access them over the web. As much I like to write my own software, des fois il y a des limites. I should be able to use a Wiki to do this.

I admit to being a little irked that a tool like CGI::Kwiki was released with insecure dependencies but hey it's only, what, version 0.18? So I rolled up my sleeves and decided to replace all the calls to glob with a localized CGI::Kwiki::globber function :

sub globber {
    my $dir    = shift;
    my $regexp = shift;

    my $dh = DirHandle->new($dir);

    if (! $dh) {
        print STDERR "Failed to open DirHandle for '$dir', $!\n";
        return undef;
    }

    return (grep { ! /^\./ && /^$regexp$/ } $dh->read());
}

Which worked fine except the program kept die-ing anyway complaining that it couldn't find a particular method relating to internationlization.

Eventually after staring at CGI::Kwiki::I18N.pm long enough to realize that the gettext_lang method was being squirted in to the symbol table at run-time (I am guilty of this kind of thing too but I'd like to think I at least add comments or POD explaining WTF is going on!) it occured to me to see if the package's _initialize method was actually returning anything.

Of course it doesn't because if it can't load the handy Locale::Maketext package it returns false without an error message :

Insecure dependency in eval while running setuid at 
 /usr/local/lib/perl5/site_perl/5.005/Locale/Maketext/GutsLoader.pm 
 line 40.
BEGIN failed--compilation aborted at 
 /usr/local/lib/perl5/site_perl/5.005/Locale/Maketext.pm line 331.
Undefined subroutine &CGI::Kwiki::I18N::gettext_lang called at 
 /usr/local/lib/perl5/site_perl/5.005/CGI/Kwiki/I18N.pm line 26.

Given that line 40 of GutsLoader.pm is trying to eval $source , die -ing in a setuid context seems perfectly reasonable but...fuck. Fuckity fuck, fuck fuck .

I look forward to explaining why an eval is really necessary to load Locale::Maketext because I expect to have to re-visit this problem for another project. However, my short-term solution for the project at hand is simply to deinstall CGI::Kwiki.

Your mileage may vary.