Discussion:
[squid-users] acl bug (when peers configured)
(too old to reply)
Michel Santos
2007-08-30 09:02:53 UTC
Permalink
There is appearently an acl bug

acls do not work for peers

#
acl all src 200.152.80.0/20
acl danger urlpath_regex -i instal\.html
http_access deny all danger
#

so far this works for "all", I mean it blocks as wanted


#
acl all src 200.152.80.0/20
acl peer src 200.152.83.40
acl danger urlpath_regex -i instal\.html
http_access deny all danger
http_access deny peer danger

#

does NOT when accessing directly from a browser from 200.152.83.40

and does NOT work when configuring localhost as proxy on 200.152.83.40

does only block when I configure the acl on 200.152.83.40's squid

same for dstdomain and other acl attributes


that is not a feature but a bug am I right?


michel
...




****************************************************
Datacenter Matik http://datacenter.matik.com.br
E-Mail e Data Hosting Service para Profissionais.
****************************************************
Henrik Nordstrom
2007-08-30 10:04:17 UTC
Permalink
Post by Michel Santos
There is appearently an acl bug
acls do not work for peers
They do work for peers, just the same as any other http client. There is
nothing special about peers in the access controls.
Post by Michel Santos
acl all src 200.152.80.0/20
Warning: Don't redefine the "all" acl unless you are very careful. It's
used in a number of defaults and meant to match "the whole world", and
results can become a bit confusing if redefined...

Instead define a "mynetwork" acl to match your clients..
Post by Michel Santos
acl danger urlpath_regex -i instal\.html
http_access deny all danger
#
so far this works for "all", I mean it blocks as wanted
#
acl all src 200.152.80.0/20
acl peer src 200.152.83.40
acl danger urlpath_regex -i instal\.html
http_access deny all danger
http_access deny peer danger
Nothing obviously wrong, apart from the use of the "all" acl..
Post by Michel Santos
does NOT when accessing directly from a browser from 200.152.83.40
Should it? When going directly Squid is not used...
Post by Michel Santos
and does NOT work when configuring localhost as proxy on 200.152.83.40
What do access.log say on both proxies?

Regards
Henrik
Michel Santos
2007-08-30 11:27:43 UTC
Permalink
Post by Henrik Nordstrom
Post by Michel Santos
There is appearently an acl bug
acls do not work for peers
They do work for peers, just the same as any other http client. There is
nothing special about peers in the access controls.
Post by Michel Santos
acl all src 200.152.80.0/20
Warning: Don't redefine the "all" acl unless you are very careful. It's
used in a number of defaults and meant to match "the whole world", and
results can become a bit confusing if redefined...
Instead define a "mynetwork" acl to match your clients..
I just did this but does not change the misbehaviour I described
Post by Henrik Nordstrom
Post by Michel Santos
acl danger urlpath_regex -i instal\.html
http_access deny all danger
#
so far this works for "all", I mean it blocks as wanted
#
acl all src 200.152.80.0/20
acl peer src 200.152.83.40
acl danger urlpath_regex -i instal\.html
http_access deny all danger
http_access deny peer danger
Nothing obviously wrong, apart from the use of the "all" acl..
ok, in fact the acl all ... is not the point and works anyway despite your
observation, what is NOT working as supposed is acl peer ... and it's
following deny clause for the peer
Post by Henrik Nordstrom
Post by Michel Santos
does NOT when accessing directly from a browser from 200.152.83.40
Should it? When going directly Squid is not used...
well well ... directly from a browser not as "always_direct" or something

I mean here when acessing the parent as client ok, since the frontend
cache is a transparent proxy it catch/intercept this connection and should
apply the acl what it in fact does so long as the IP does not part of "acl
peer src"

when I change the "acl peer src *IP*" then the acl works for this machine
as well as for all not_peer_clientes of the frontend cache


*THIS* is the thing here: that any acl configured on the frontend cache is
not beeing applied to any request from the peer


michel

...




****************************************************
Datacenter Matik http://datacenter.matik.com.br
E-Mail e Data Hosting Service para Profissionais.
****************************************************
Henrik Nordstrom
2007-08-30 12:11:31 UTC
Permalink
Post by Michel Santos
*THIS* is the thing here: that any acl configured on the frontend cache is
not beeing applied to any request from the peer
Then check your http_access rules. You have something else in there...

There is absolutely nothing special about peers in access controls. They
are just HTTP clients just as any other HTTP client.

Regards
Henrik
Michel Santos
2007-08-30 13:26:39 UTC
Permalink
Post by Henrik Nordstrom
Post by Michel Santos
*THIS* is the thing here: that any acl configured on the frontend cache is
not beeing applied to any request from the peer
Then check your http_access rules. You have something else in there...
There is absolutely nothing special about peers in access controls. They
are just HTTP clients just as any other HTTP client.
ok, then I will isolate a pair from the cluster at night and doublecheck
everything
thank's so far

michel
...




****************************************************
Datacenter Matik http://datacenter.matik.com.br
E-Mail e Data Hosting Service para Profissionais.
****************************************************
Michel Santos
2007-08-31 08:17:34 UTC
Permalink
Post by Henrik Nordstrom
Post by Michel Santos
*THIS* is the thing here: that any acl configured on the frontend cache is
not beeing applied to any request from the peer
Then check your http_access rules. You have something else in there...
hey thank you!

I found it, there was an extra 'http_access allow peer' above the acls in
two older frontend squids

looking this over means that when the IP address of any 'acl peer src $1'
match the IP range of 'acl all src ip/mask' then I do not need to specify
an additional 'http_access deny peer we_acl' if 'http_access deny all
we_acl' is defined before right


michel


...




****************************************************
Datacenter Matik http://datacenter.matik.com.br
E-Mail e Data Hosting Service para Profissionais.
****************************************************
Henrik Nordstrom
2007-08-31 10:18:27 UTC
Permalink
Post by Michel Santos
looking this over means that when the IP address of any 'acl peer src $1'
match the IP range of 'acl all src ip/mask' then I do not need to specify
an additional 'http_access deny peer we_acl' if 'http_access deny all
we_acl' is defined before right
Probably. But I don't have a good view of your http_access rules..


in a src acl a network speification (ip/mask) matches all IPs in that
network, including the network and broadcast addresses.

192.168.1.0/24 is the same as 192.168.1.0-192.168.1.255

Note: 192.168.1.1/24 is an error, and read as 192.168.1.0/24 with a big
fat warning.

Regards
Henrik
Michel Santos
2007-08-31 12:24:22 UTC
Permalink
Post by Henrik Nordstrom
Post by Michel Santos
looking this over means that when the IP address of any 'acl peer src $1'
match the IP range of 'acl all src ip/mask' then I do not need to specify
an additional 'http_access deny peer we_acl' if 'http_access deny all
we_acl' is defined before right
Probably. But I don't have a good view of your http_access rules..
they are exactly the same for 'all' and 'peers'

under the acl definition list come the deny for all and peer and under
them at the end the allow clauses
Post by Henrik Nordstrom
in a src acl a network speification (ip/mask) matches all IPs in that
network, including the network and broadcast addresses.
192.168.1.0/24 is the same as 192.168.1.0-192.168.1.255
really ;)

a range indicator is allowed?

or did you wrote this only for better understandings what /24 means?
Post by Henrik Nordstrom
Note: 192.168.1.1/24 is an error, and read as 192.168.1.0/24 with a big
fat warning.
but 192.168.1.1/32 is not

michel

...




****************************************************
Datacenter Matik http://datacenter.matik.com.br
E-Mail e Data Hosting Service para Profissionais.
****************************************************
Henrik Nordstrom
2007-08-31 19:22:23 UTC
Permalink
Post by Michel Santos
Post by Henrik Nordstrom
192.168.1.0/24 is the same as 192.168.1.0-192.168.1.255
really ;)
a range indicator is allowed?
Yes.

The full specification is

IPA-IPB/MASK

where IPB defaults to IPA if not specified, and /MASK defaults to /32 if
not specified (at least unless you use a old now obsolete Squid version
where it guesses the mask size based on the format of the IP...)
Post by Michel Santos
or did you wrote this only for better understandings what /24 means?
Both.
Post by Michel Santos
Post by Henrik Nordstrom
Note: 192.168.1.1/24 is an error, and read as 192.168.1.0/24 with a big
fat warning.
but 192.168.1.1/32 is not
Correct. You are getting a hang of this ;-)

Regards
Henrik
Michel Santos
2007-08-31 22:16:30 UTC
Permalink
Post by Henrik Nordstrom
Post by Michel Santos
Post by Henrik Nordstrom
192.168.1.0/24 is the same as 192.168.1.0-192.168.1.255
really ;)
a range indicator is allowed?
Yes.
I was asking about the dash '-'
Post by Henrik Nordstrom
The full specification is
IPA-IPB/MASK
well, no need teaching a dog to bark ;)
Post by Henrik Nordstrom
where IPB defaults to IPA if not specified, and /MASK defaults to /32 if
not specified (at least unless you use a old now obsolete Squid version
where it guesses the mask size based on the format of the IP...)
well, I guess in 2.6 is something wrong at this special point, unless some
secret work fixed it (I have not checked > 14S), if you remember this is
not working with any 2.6 when coming from a local address, but with 2.5 it
is

shortcut:

#on 127.0.0.2
acl peer src 127.0.0.1

gets 'access denied' for all requests from 127.0.0.1

#on 127.0.0.2
acl peer src 127.0.0.1/32

and 127.0.0.1 goes through ...


michel

...




****************************************************
Datacenter Matik http://datacenter.matik.com.br
E-Mail e Data Hosting Service para Profissionais.
****************************************************
Henrik Nordstrom
2007-08-31 22:39:33 UTC
Permalink
Post by Michel Santos
well, I guess in 2.6 is something wrong at this special point, unless some
secret work fixed it (I have not checked > 14S), if you remember this is
not working with any 2.6 when coming from a local address, but with 2.5 it
is
#on 127.0.0.2
acl peer src 127.0.0.1
gets 'access denied' for all requests from 127.0.0.1
#on 127.0.0.2
acl peer src 127.0.0.1/32
and 127.0.0.1 goes through ...
Then I guess you must have changed something else as well. 127.0.0.1
127.0.0.1/32 and 127.0.0.1/255.255.255.255 is all equivalent and matches
the exact ip 127.0.0.1, and has always been..

The magic autodetection of the mask size in earlier releases only kick
in if the ip ends in .0, but was inconsistent and therefore removed...

There has not been any changes in this part of the code since 31 July
2006 when the mask size detection was removed..

Regards
Henrik
Michel Santos
2007-09-01 00:10:31 UTC
Permalink
Post by Henrik Nordstrom
Post by Michel Santos
well, I guess in 2.6 is something wrong at this special point, unless some
secret work fixed it (I have not checked > 14S), if you remember this is
not working with any 2.6 when coming from a local address, but with 2.5 it
is
#on 127.0.0.2
acl peer src 127.0.0.1
gets 'access denied' for all requests from 127.0.0.1
#on 127.0.0.2
acl peer src 127.0.0.1/32
and 127.0.0.1 goes through ...
Then I guess you must have changed something else as well. 127.0.0.1
127.0.0.1/32 and 127.0.0.1/255.255.255.255 is all equivalent and matches
the exact ip 127.0.0.1, and has always been..
hmm, I haven't changed anything else than the squid version
Post by Henrik Nordstrom
The magic autodetection of the mask size in earlier releases only kick
in if the ip ends in .0, but was inconsistent and therefore removed...
this is what scares me to death: 'magic' ...

my obs.:
magic starts where maths ends ... ;)
Post by Henrik Nordstrom
There has not been any changes in this part of the code since 31 July
2006 when the mask size detection was removed..
well, I was trying .. asking, begging 'endless' (=>_almost) for six month
with logs until i did finally that scary magic touch of /32 and bingo ..
everything works


michel
...




****************************************************
Datacenter Matik http://datacenter.matik.com.br
E-Mail e Data Hosting Service para Profissionais.
****************************************************
Henrik Nordstrom
2007-09-01 08:31:03 UTC
Permalink
Post by Michel Santos
well, I was trying .. asking, begging 'endless' (=>_almost) for six month
with logs until i did finally that scary magic touch of /32 and bingo ..
everything works
And if you now remove the /32?

Regards
Henrik
Michel Santos
2007-09-01 09:22:53 UTC
Permalink
Post by Henrik Nordstrom
Post by Michel Santos
well, I was trying .. asking, begging 'endless' (=>_almost) for six month
with logs until i did finally that scary magic touch of /32 and bingo ..
everything works
And if you now remove the /32?
just checked

'now' it is working

when the secret service fixed it? I never saw a note


michel

...




****************************************************
Datacenter Matik http://datacenter.matik.com.br
E-Mail e Data Hosting Service para Profissionais.
****************************************************

Loading...