Re: Can't deny access to accelerator

From: <P.Lister@dont-contact.us>
Date: Thu, 12 Dec 96 12:56:09 +0000

OK, so I hit an Undocumented Feature c(squid 1.1.0).
client_side.h says...

    if (httpd_accel_mode && !Config.Accel.withProxy && r->protocol !=
PROTO_CACH
EOBJ) {
        /* this cache is an httpd accelerator ONLY */
        if (icpState->accel == 0)
            answer = 0;
    } else {

i.e. "if you're just an accelerator, I'm silently turning off access
control". Guys, this is a BIG problem, and even "debug_option 28,9"
(many thanks to Neil Murray for that), doesn't tell me that there will
be no ACL check.

I have a WWW server with part of URL space restricted by IP address
(before anyone lectures me, I know this is "insecure"; it's for
resource limitation and info of the "local notice board" variety than
high security). But "www.cranfield.ac.uk" points to the accelerator,
to handle the majority of requests efficiently. Clearly, access
control on WWW server and accelerator (and the local proxy, which is a
different Squid instance, potentially on a different system) must
agree to prevent things "leaking".

Yes, access control consumes resources, and where it's not needed
should be turned off, but please can I have a switch, independent of
proxy behaviour ("enable_access_control"?). And please TELL ME with a
suitable debug message.

BTW, would someone like to reassure me that turning off access control
in this way doesn't permit unlimited access to "manager" functions as
well?

In the meantime, I'll just set "http_accel_with_proxy on", to make
access control work.

Peter Lister Email: p.lister@cranfield.ac.uk
Computer Centre, Cranfield University Voice: +44 1234 754200 ext 2828
Cranfield, Bedfordshire MK43 0AL UK Fax: +44 1234 751814
------------------------------------------------------------------------
     (1) "Yes" (2) "No" (3) "That would be an ecumenical matter"
------------------------------------------------------------------------
Received on Thu Dec 12 1996 - 05:00:12 MST

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:33:53 MST