Re: Confused "deny_info" logic

Duane said:

> joern@TechFak.Uni-Bielefeld.DE writes:
>
> >> Yes, but a RULE fails because just one ACL fails.
> >
> >No, a rule can fail, because several ACLs fail, and if one acl appears in
>
> As soon as one ACL in a rule fails, we don't need to check any others.

OK... I think I understand the logic, but I disagree with it.

A deny_info URL is returned for a particular "acl" (in the terms of
the squid config file) when that "acl" causes a http_access rule to
deny access to the current request. Since the "acls" on the
http_access line are implicitly ANDed together , this means that it
will be the *first* "acl" to evaluate FALSE (or TRUE if it's negated)
in the case of http_access allow, OR the *last* "acl" to evaluate TRUE
(FALSE if it's negated) in the case of http_access deny.

Sure enough, I moved the "hypernews" "acl" to the end of my
http_access deny line in the original example, and Squid returned the
correct URL location header. Eeek. I wouldn't know where to start
explaining that to most web folk here. Duane, I'm with Joern here -
this is a bug.

Part of the problem is terminology - an acl (in every case I can think
of) is a list of entities which can perform a particular action, and
necessarily includes a correlation between the two. Squid's "acls" are
equivalent to user groups: they define whether the current request is
a member of the group or not; they don't control permission.

The http_access rules are actually the true "access control lists";
they associate membership of a group or combination of groups with the
allow/deny permission. Speaking as a webmaster, it is *these* rules
which I want to relate to the appropriate messages defined by the
deny_info lines. I don't care *how* the rule failed - I want to know
that *this* rule failed and generate *that* message.

It also feels wrong that proper Boolean expressions aren't available,
so that I rely on De Morgan's law to coerce ANDs and NOTs into an
OR. I'm expressing my rules they way I am...

http_access deny hypernews !rmcs !cranfield

...because I *can't* say things like...

http_access deny hypernews AND NOT ( rmcs OR cranfield )

...which feels far more sensible to me. Better yet would be something
like this...

group hypernews urlpath_regex ^/hypernews
group local group rmcs OR group cranfield
deny_info notlocal URL http:www.cranfield.ac.uk/notlocal.html
http_access deny (hypernews AND NOT local) deny_info notlocal

"notlocal" here names a deny_info line, so that it can be associated
with one or more http_access rules. BTW, the deny_info line should be
capable of generating messages in more than one way e.g. by generating
a text error message (with error code 400), by a Location: header, or
by letting an external script handle things.

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 Tue Jan 07 1997 - 03:25:12 MST