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 zoo.uvm.edu/www.uvm.edu
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 https://www.uvm.edu/htpasswd 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
jsmith.
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
denied.
Monkey Wrench 2: The .htaccess file might also contains the directives
SSLRequire
SSLErrorDocument 403 https://www.uvm.edu/~whatever/protected
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. \\ http://www.uvm.edu/skivt-l |
| Voice:802-656-1254 FAX:802-???-???? vv |
| aim:goim?screenname=maddogskideath http://www.uvm.edu/~waw/ |
|
