Merge branch 'master' into autoconfig

Conflicts:

	IkiWiki/Plugin/git.pm
	debian/changelog
	po/ikiwiki.pot

2 files changed, 92 insertions, 8 deletions

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]]