OSU problem

[Willem Grooters]

Perhaps not the right place, but who knows...

A customers runs OSU webserver for a few web-based (CGI) applications. No trouble at all, until a few days ago there has been an update of one of these scripts, now that one fails with the folowing message:

The server was unable to return the requested document because access controls placed on that document by the HTTP server deny access.
Please check with the web master for configuration corrections.

I'm not at all familiar with SOU and couldn't find out what's the problem. I _have_ checked the file protections, it's all Ok.
Nor Alan Winston's book, nor the OSU website gave me a clue what's the problem. The application owner told me that the solution would be very obvious - once you know what it is. He didn't remember....

Any idea's?
If you need more ingfo, please tell me what you need, I'll give you the details you need.

Willem

[Mobeen_1]

Willem,
I would check couple of things like permissions of the directory and file and secondly on the virtual directory mapping (this is the mapping that you define on your web server, example mtdat = disk$user10:[prog.mt.dat]

If these are correct, would you mind giving us details on the script? what does it try to do and so on

rgds
Mobeen

[Willem Grooters]

Mobeen,

We already checked ownership on files and directories, it's all HTTP_SERVER and protection for owner is READ at least. So that is not the problem.
Do I have to check some files as well, I read something on .PROT files that couild limit access, and HTTP_PATHS.CONF that contains mapping. Should I look there for inconsistence?
What about HTTP_DIRECTORY.CONF - could that miss something?

Alas, I know only about the basics of the application since it is used outside the web-interface as well. What I know about the web interface is that the scripts set up quite a lot of symbols and logicals, but the exact constrcution remains obscure at the moment.

I don't know either what the update consisted of. New versions of existing scripts, that's for sure, but I cannot exclude that new directories and files have been added. My guess is, after re-reading the documentation on OSU, that there is something wrong in configuration.

[Mobeen_1]

Willem,
I totally agree with you that there is some configuration issue out here. I don't currently have OSU out here, so its difficult for me to get the exact files. But you probably could start making some appropiate changes in the configuration files like HTTPD.CONF and so on after making a backup copy and restart to see if it works.


Do look at the following link and see if it rings a bell

http://bob.marlboro.edu/~bluhrs/it1/homefun1.html

I found that the issue below which is provided in the link above may be handy to you

TCP Connection Analysis
Generating an Interesting TCP Connection
A more interesting TCP connection is one that carries an HTTP request to a web server, which results in an reply. The following shows a telnet request to the HTTP/web-server port (80) of "www.usp.ac.fj", at The University of the South Pacific:

[root@carson-city]# tcpdump host carson-city -w l_telhtt1
tcpdump: listening on eth0

[kid@carson-city]$ telnet www.usp.ac.fj 80
Trying 144.120.8.5...
Connected to maya.USP.ac.FJ.
Escape character is '^]'.
GET /HTTP/1.0



The server was unable to return the requested document because access
controls placed on that document by the HTTP server deny access.

Please check with the web master for configuration corrections.


Connection closed by foreign host.

^C
47 packets received by filter
0 packets dropped by kernel

maya.usp.ac.fj is unhappy with the request because it expects a space between the resource requested and the HTTP version (i.e., it's looking for 'GET / HTTP/1.0', not GET /HTTP/1.0')
The "request" consists of 19 bytes (GET /HTTP/1.0, plus 3 cr-lf pairs). The reply is 280 bytes of data. A total of 47 packets are captured by tcpdump, of which 11 packets are relevant to the HTTP request and response. As before, packets that are part of the executing tcpdump on carson-city from my dialup system are ignored.



rgds
Mobeen

[Willem Grooters]

Mobeen,

Interresting issue! I'll check that! Has to do with scripting, I guess. Will ask user where this happens...

Willem

[Mobeen_1]

Willem,
As you pointed out that you have not made any configuration changes on the OSU and also the fact that this problem started after the developers make some code changes :-), makes me believe that it most certainly will be an application issue

rgds
Mobeen

[Willem Grooters]

Oh, sure.
But do NOT over-estimate system managers that install patches of applications. Some tend to be far to self-confident and srew up a working system (I won't say this one did. He's good. Oh well, some developers do as well :-D)
I just checked the code - for what I've found, but there's no GET in there anywhere.
I'll wait until the expert is back, nect Tuesday. Hopefully he'll tell me what's te cause - and the solution. I'll keep you informed..
(Anyone else an idea? Still welcome!)

[Joseph Huber_1]

To find out at what particular place in the
http path translation and access control checking the error is generated, the OSU server manager should raise the logging level to 5.
easiest using the web interface
http(s)://your_server/htbin/servermaint/http_manage

Then You can find in access.log the step cauding the error.

[Mobeen_1]

Willem,
Just keep us updated and let us know when the issue is successfully resolved

regards
Mobeen

[Martin P.J. Zinser]

Hello Willem,

one thing to keep in mind with security and OSU is that the >>first<< rule that applies to
a given URI is the one that determines the outcome. So if you got a rule that forbids access to the document you can have as many rules afterwards in the config allowing access you still will not get the document.
(And vice versa by the way ;-)

One possible test to nail this down as a config issue: Find an unimportant script that works, copy the new one to use the name of the working one. If it starts working with this name you really have a config problem on your hands. If it still fails maybe something wacky is going on with the app.

Greetings, Martin

[Antoniov.]

Hello Willem,
do you enable any override protection? On Apache you can demand protection on every folder usinf directive in .htaccess; this means you can authorize in http.conf but user is unauthorized by .htaccess file. If OSU is like Apache you might find this situation.

@Antoniov