It looks like nsperm had a fair amount of code cleanup in AOLserver 4, so you'll want to confirm that you fetched the 4 version of the module from CVS and compiled that. (I don't think there were many functional changes.)
I believe there's a serious but easily fixed bug in AOLserver 4.x's nsperm - someone please correct me if I'm wrong. (I emailed the ACT about this in Nov. but didn't get a response and forgot about it.) It looks to me like the logic for implicit allow's is reversed. As I understand it, what is supposed to happen is that an "allowgroup" command in the perms file implicitly denies access to other groups, and a "denygroup" command in the perms file implicitly allows access to other groups.
Currently, in AllowDenyCmd, permPtr->implicit_allow is set to 1 for the allow commands and 0 for the deny commands, the opposite of what should happen.
Here's a patch (last is only important one)
cvs server: Diffing .
Index: nsperm.c
===================================================================
RCS file: /cvsroot/aolserver/aolserver/nsperm/nsperm.c,v
retrieving revision 1.8
diff -u -r1.8 nsperm.c
--- nsperm.c 7 Mar 2003 18:08:50 -0000 1.8
+++ nsperm.c 5 Feb 2004 03:13:26 -0000
@@ -242,7 +242,7 @@
* AuthProc --
*
* Authorize a URL--this callback is called when a new
- * connection is recieved
+ * connection is received
*
* Results:
* NS_OK: accept;
@@ -312,7 +312,7 @@
}
/*
- * Check for a vaild user address.
+ * Check for a valid user address.
*/
if (!ValidateUserAddr(userPtr, peer)) {
@@ -833,7 +833,7 @@
Tcl_InitHashTable(&permPtr->denygroup, TCL_STRING_KEYS);
Ns_UrlSpecificSet(servPtr->server, method, url, uskey, permPtr, flags, NULL);
}
- permPtr->implicit_allow = allow;
+ permPtr->implicit_allow = !allow; // JCR: Implicitly we do the opposite of the command
if (user) {
if (allow) {
(void) Tcl_CreateHashEntry(&permPtr->allowuser, key, &new);
