diff options
Diffstat (limited to 'doc/plugins')
| -rw-r--r-- | doc/plugins/autoindex.mdwn | 6 | ||||
| -rw-r--r-- | doc/plugins/contrib/unixauth.mdwn | 68 | ||||
| -rw-r--r-- | doc/plugins/contrib/unixauth/discussion.mdwn | 32 | ||||
| -rw-r--r-- | doc/plugins/creole.mdwn | 2 | ||||
| -rw-r--r-- | doc/plugins/creole/discussion.mdwn | 7 | ||||
| -rw-r--r-- | doc/plugins/write.mdwn | 44 |
6 files changed, 129 insertions, 30 deletions
diff --git a/doc/plugins/autoindex.mdwn b/doc/plugins/autoindex.mdwn index 66e0163c2..03e2d12f3 100644 --- a/doc/plugins/autoindex.mdwn +++ b/doc/plugins/autoindex.mdwn @@ -2,6 +2,6 @@ [[!tag type/useful]] This plugin searches for [[SubPages|ikiwiki/subpage]] with a missing parent -page, and generates a parent page for them. The generated page content is -controlled by the autoindex [[template|wikitemplates]], which by default, -uses a [[map]] to list the SubPages. +page, and generates the parent pages. The generated page content is +controlled by the `autoindex.tmpl` [[template|wikitemplates]], which by +default, uses a [[map]] to list the SubPages. diff --git a/doc/plugins/contrib/unixauth.mdwn b/doc/plugins/contrib/unixauth.mdwn index 12f885c33..2de6fc51f 100644 --- a/doc/plugins/contrib/unixauth.mdwn +++ b/doc/plugins/contrib/unixauth.mdwn @@ -3,9 +3,36 @@ This plugin authenticates users against the Unix user database. It presents a similar UI to [[plugins/passwordauth]], but simpler, as there's no need to be able to register or change one's password. -[pwauth](http://www.unixpapa.com/pwauth/) must be installed and working. In particular, it must be configured to recognize the UID of the calling web server, or authentication will always fail. Set `pwauth_path` to the full path of your pwauth binary. +To authenticate, either [checkpassword](http://cr.yp.to/checkpwd.html) or [pwauth](http://www.unixpapa.com/pwauth/) must be installed and configured. `checkpassword` is strongly preferred. If your web server runs as an unprivileged user -- as it darn well should! -- then `checkpassword` needs to be setuid root. (Or your ikiwiki CGI wrapper, I guess, but don't do that.) Other checkpassword implementations are available, notably [checkpassword-pam](http://checkpasswd-pam.sourceforge.net/). -As [with passwordauth](/security/#index14h2), be wary of sending usernames and passwords in cleartext. Unlike with passwordauth, sniffing these credentials can get an attacker much further than mere wiki access. SSL with this plugin is a __must__. +Config variables that affect the behavior of `unixauth`: + +* `unixauth_type`: defaults to unset, can be "checkpassword" or "pwauth" +* `unixauth_command`: defaults to unset, should contain the full path and any arguments +* `unixauth_requiressl`: defaults to 1, can be 0 +* `sslcookie`: needs to be 1 if `unixauth_requiressl` is 1 (perhaps this should be done automatically?) + +__Security__: [As with passwordauth](/security/#index14h2), be wary of sending usernames and passwords in cleartext. Unlike passwordauth, sniffing `unixauth` credentials can get an attacker much further than mere wiki access. Therefore, this plugin defaults to not even _displaying_ the login form fields unless we're running under SSL. Nobody should be able to do anything remotely dumb until the admin has done at least a little thinking. After that, dumb things are always possible. ;-) + +`unixauth` tests for the presence of the `HTTPS` environment variable. `Wrapper.pm` needs to be tweaked to pass it through; without that, the plugin fails closed. + +[[!toggle id="diff" text="Wrapper.pm.diff"]] + +[[!toggleable id="diff" text=""" + + --- Wrapper.pm.orig 2008-07-29 00:09:10.000000000 -0400 + +++ Wrapper.pm + @@ -28,7 +28,7 @@ sub gen_wrapper () { #{{{ + my @envsave; + push @envsave, qw{REMOTE_ADDR QUERY_STRING REQUEST_METHOD REQUEST_URI + CONTENT_TYPE CONTENT_LENGTH GATEWAY_INTERFACE + - HTTP_COOKIE REMOTE_USER} if $config{cgi}; + + HTTP_COOKIE REMOTE_USER HTTPS} if $config{cgi}; + my $envsave=""; + foreach my $var (@envsave) { + $envsave.=<<"EOF" + +"""]] [[!toggle id="code" text="unixauth.pm"]] @@ -40,13 +67,26 @@ As [with passwordauth](/security/#index14h2), be wary of sending usernames and p } my $ret=0; - if (! exists $config{pwauth_path}) { - $config{pwauth_path}="/usr/libexec/pwauth"; + if (! exists $config{unixauth_type}) { + # admin needs to carefully think over his configuration + return 0; + } + elsif ($config{unixauth_type} eq "checkpassword") { + open UNIXAUTH, "|$config{unixauth_command} true 3<&0" or die("Could not run $config{unixauth_type}"); + print UNIXAUTH "$user\0$password\0Y123456\0"; + close UNIXAUTH; + $ret=!($?>>8); + } + elsif ($config{unixauth_type} eq "pwauth") { + open UNIXAUTH, "|$config{unixauth_command}" or die("Could not run $config{unixauth_type}"); + print UNIXAUTH "$user\n$password\n"; + close UNIXAUTH; + $ret=!($?>>8); + } + else { + # no such authentication type + return 0; } - open PWAUTH, "|$config{pwauth_path}" or die("Could not run pwauth"); - print PWAUTH "$user\n$password\n"; - close PWAUTH; - $ret=!($?>>8); if ($ret) { my $userinfo=IkiWiki::userinfo_retrieve(); @@ -69,6 +109,17 @@ As [with passwordauth](/security/#index14h2), be wary of sending usernames and p my $session=$params{session}; my $cgi=$params{cgi}; + # if not under SSL, die before even showing a login form, + # unless the admin explicitly says it's fine + if (! exists $config{unixauth_requiressl}) { + $config{unixauth_requiressl} = 1; + } + if ($config{unixauth_requiressl}) { + if ((! $config{sslcookie}) || (! exists $ENV{'HTTPS'})) { + die("SSL required to login. Contact your administrator.<br>"); + } + } + if ($form->title eq "signin") { $form->field(name => "name", required => 0); $form->field(name => "password", type => "password", required => 0); @@ -93,6 +144,7 @@ As [with passwordauth](/security/#index14h2), be wary of sending usernames and p ); } + # XXX is this reachable? looks like no elsif ($submittype eq "Login") { $form->field( name => "name", diff --git a/doc/plugins/contrib/unixauth/discussion.mdwn b/doc/plugins/contrib/unixauth/discussion.mdwn new file mode 100644 index 000000000..c4f5ff269 --- /dev/null +++ b/doc/plugins/contrib/unixauth/discussion.mdwn @@ -0,0 +1,32 @@ +The security of this plugin scares me. As noted in the plugin +documentation, you basically have to use it with SSL, since snooping on the +login password doesn't give you an essentially useless account -- it gives +you an actual account on the machine! + +Also, apparently pwauth defers *all* auth attempts if one fails, and it +does this by using a lock file, and sleeping after a failed auth attempt. +Which is needed to avoid brute-forcing, since this is a significant +password.. but how will that interact with ikiwiki? Well, ikiwiki _also_ +uses a lock file. So, at a minimum, someone can not only try to brute-force +the pwauth password, but the ikiwiki processes that stack up due to that +will also keep ikiwiki's lock held. Which basically DOSes the wiki for +everyone else; noone else can try to log in, or log out, or edit a page, +all of which require taking the lock. + +So I don't think I'll be accepting this plugin into ikiwiki itself.. +--[[Joey]] + +Thanks for the comments. That's definitely an undesirable interaction between pwauth and ikiwiki; in my current application it wouldn't be a serious problem, but I'd like this plugin to be general-purpose and safe enough for inclusion in ikiwiki. It's the system-users-are-wiki-users idea I'm married to here, not pwauth itself; can you suggest another approach I might take? +-- [[schmonz]] + +> Have you considered using [[plugins/httpauth]] and then the appropriate apache module? There are apache modules like [mod_authnz_external](http://unixpapa.com/mod_auth_external.html) that might help. The advantage of these solutions is that they usually make the security implications explicit. -- Will + +Actually, yes. That's how I made sure I had pwauth working to begin with. I'm partial to the form-based approach because I'm not aware of any way to reliably "log out" browsers from HTTP authentication. If that *is* reliably possible, then I worked way too hard for no reason. ;-) +-- [[schmonz]] + +I've added support for [checkpassword](http://cr.yp.to/checkpwd/interface.html), since those generally don't have any rate-limiting cleverness to interfere with ikiwiki's, and made a few other changes. Please check out the plugin docs again and let me know if this is closer to being acceptable. +-- [[schmonz]] + +> I actually think that the rate limiting is a good thing. After all, +> ikiwiki doesn't do its own login rate limiting. Just need to find a way +> to disentangle the two locks. --[[Joey]] diff --git a/doc/plugins/creole.mdwn b/doc/plugins/creole.mdwn index b6861ab26..ed347e2c5 100644 --- a/doc/plugins/creole.mdwn +++ b/doc/plugins/creole.mdwn @@ -12,5 +12,5 @@ wiki markup formats, so should be fairly easy to guess at. There is also a [CheatSheet](http://www.wikicreole.org/wiki/CheatSheet). Links are standard [[WikiLinks|ikiwiki/WikiLink]]. Links and -[[PreProcessorDirectives]] inside `{{{ }}}` blocks are still expanded, +[[ikiwiki/PreProcessorDirectives]] inside `{{{ }}}` blocks are still expanded, since this happens before the creole format is processed. diff --git a/doc/plugins/creole/discussion.mdwn b/doc/plugins/creole/discussion.mdwn new file mode 100644 index 000000000..a31f9cf83 --- /dev/null +++ b/doc/plugins/creole/discussion.mdwn @@ -0,0 +1,7 @@ +I've installed Text::WikiCreole 0.05 and enabled the plugin, but I get an error when rebuilding the wiki: `Undefined subroutine &IkiWiki::Plugin::creole::creole_custombarelinks called at /usr/pkg-20080723/lib/perl5/vendor_perl/5.8.0/IkiWiki/Plugin/creole.pm line 23`. Is there a newer Text::WikiCreole I'm not finding online? +-- [[schmonz]] + +> There's a patch in the debian package of libtext-wikicreole-perl that +> adds that option. I'm not sure what the status of it being released +> upstream is, though IIRC I was assured it would not be a problem. +> --[[Joey]] diff --git a/doc/plugins/write.mdwn b/doc/plugins/write.mdwn index 04b6ea8e9..77210d35c 100644 --- a/doc/plugins/write.mdwn +++ b/doc/plugins/write.mdwn @@ -128,26 +128,34 @@ of a plugin. hook(type => "preprocess", id => "foo", call => \&preprocess); -Replace "foo" with the command name that will be used inside brackets for -the preprocessor directive. - -Each time the directive is processed, the referenced function (`preprocess` -in the example above) is called, and is passed named parameters. A "page" -parameter gives the name of the page that embedded the preprocessor -directive, while a "destpage" parameter gives the name of the page the -content is going to (different for inlined pages), and a "preview" -parameter is set to a true value if the page is being previewed. All -parameters included in the directive are included as named parameters as -well. Whatever the function returns goes onto the page in place of the +Replace "foo" with the command name that will be used for the preprocessor directive. -An optional "scan" parameter, if set to a true value, makes the hook be -called during the preliminary scan that ikiwiki makes of updated pages, -before begining to render pages. This parameter should be set to true if -the hook modifies data in `%links`. Note that doing so will make the hook -be run twice per page build, so avoid doing it for expensive hooks. (As an -optimisation, if your preprocessor hook is called in a void contets, you -can assume it's being run in scan mode.) +Each time the directive is processed, the referenced function (`preprocess` +in the example above) is called. Whatever the function returns goes onto +the page in place of the directive. Or, if the function aborts using +`error()`, the directive will be replaced with the error message. + +The function is passed named parameters. First come the parameters set +in the preprocessor directive. These are passed in the same order as +they're in the directive, and if the preprocessor directive contains a bare +parameter (example: `\[[!foo param]]`), that parameter will be passed with +an empty value. + +After the parameters from the preprocessor directive some additional ones +are passed: A "page" parameter gives the name of the page that embedded the +preprocessor directive, while a "destpage" parameter gives the name of the +page the content is going to (different for inlined pages), and a "preview" +parameter is set to a true value if the page is being previewed. + +If `hook` is passed an optional "scan" parameter, set to a true value, this +makes the hook be called during the preliminary scan that ikiwiki makes of +updated pages, before begining to render pages. This should be done if the +hook modifies data in `%links`. Note that doing so will make the hook be +run twice per page build, so avoid doing it for expensive hooks. (As an +optimisation, if your preprocessor hook is called in a void context, you +can assume it's being run in scan mode, and avoid doing expensive things at +that point.) Note that if the [[htmlscrubber]] is enabled, html in [[ikiwiki/PreProcessorDirective]] output is sanitised, which may limit what |