It's not like I needed another reason to dislike Wikis.
Some background :
I
like
CGI::Kwiki.
The target machine uses cgiwrap and not suExec (for a variety of
good reasons.)
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.
As such, the only way to create a secure and authenticated Kwiki is
to :
Create a special
kwiki
user with restricted permissions.
Create a special
Directory
directive in your Apache config file with the requisite options for
enabling CGI scripts and doing authentication.
Remove all world readable and writable (eek!) permissions from
the Kwiki config files and databases
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.)
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.
Directory
directive in your Apache config file with the requisite options for enabling CGI scripts and doing authentication.glob
function which, rightly, causes setuid Perl scripts to complaining about .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
but hey it's only, what, version 0.18? So I rolled up my sleeves and decided to replace all the calls toglob
with a localizedCGI::Kwiki::globber
function :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 :
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.