This being a technology discussion list, let's discuss what happens.

The web server is just a program running on a computer that reads  
requested files from disk and sends them off to eager browsers. The  
computer program is marked as "owned" by some user on the system, in  
our case user "nobody" . All users are assigned to one or more groups  
on the system. nobody is assigned only to group nobody.

Similarly, all files on the system are marked as owned by a  
particular user and a particular group.

If the permissions on the folders enclosing the protected files are  
set to something like "Owner:read,write ; Group:no permissions ;  
others:read " , then no user in the same group as the "group owner"  
of that file can read the file. But, all other users on the system  
CAN read it.

Well, since virtually all users of the  
cluster are assigned minimally to a special group named "usr,"  most  
files on the web server are also marked as owned by group usr. So  
virtually every other user on zoo is locked out of that document --  
except for user nobody, who lives in group nobody. So thank goodness,  
the web server can read the document and server to anyone on the web.

Now comes the two monkey wrenches. Note that the "standard?"  on-line  
form at generates these two Monkey  
Wrenches, which by themselves are normally harmless and quite useful.

Monkey Wrench 1: Many use the UVM supplied "AuthDCE" method of  
password protecting files using zoo user names (aka NetIDs or email  
passwords) has a useful side effect: once authenticated via AuthDCE,  
for that user and these set of password protected pages and scripts,  
the web server stops running as user nobody and starts running the  
authenticated user, say, jsmith. And all the rights and privileges of  

This can be a good thing, if you want to write a script that can read  
and write files owned by jsmith. But this turns out to be a bad thing  
if trying to read files NOt owned by jsmith. Because now, all those  
files marked as "no access to members of group usr" are trying to be  
accessed by a program owned by a user in group usr. So, access is  

Monkey Wrench 2: The .htaccess file might also contains the directives

	SSLErrorDocument 403

The first one is designed to return an error if someone tried to  
access the protected material  using an non-secure protocol  -- just  
http:// , without the all important s. We want to use the https://  
"SSL Secure Sockets Layer" protocol, so no one steals the user name  
and password. So, if someone tries to access the url as http:// , the  
server returns an error

The second one says, if there is a server error, try using the  
following URL. if that URL is the secure (https://) URL of the  
protected documents, then the two directives effectively and quietly  
force anyone trying to use the http address directly to the secure  
https address, and everything is fine.

But Monkey Wrench One ALWAYS returns an error. And Monkey Wrench Two  
says, well, try the same address again. But Monkey Wrench One ALWAYS  
returns an error. And Monkey Wrench Two says, well, try the same  
address again. But Monkey Wrench One ALWAYS returns an error. And  
Monkey Wrench Two says, well, try the same address again.

So, what's the fix? You might try

	  AuthType Kerberos

although I'm seeming to have troubles getting that to work myself.

On Apr 16, 2008, at 9:35 AM, Ben Ware wrote:
> Ben,
> I believe it was due to a change in file permissions for the  
> enclosing folder;

| Wesley Alan Wright <mailto:[log in to unmask]>                   |
| Academic Computing Services       __0__                             |
| Room 407 Lafayette Building      / \ | \                            |
| University of Vermont              \77                              |
| Burlington, Vermont 05405-0160 USA. \\  |
| Voice:802-656-1254 FAX:802-???-????  vv                             |
| aim:goim?screenname=maddogskideath    |