I'm thinking to improve the behavior of the "continue" option. Currently 
it allows to go on examining other rules when the client is not blocked. 
I think it would be better to go on examining other rules only in the 
case the destination do not match. The difference is that you don't go 
on if the destination matches and the client is not blocked.

Here following I describe a typical scenario currently not supported by 
squidguard, which would be supported by the new "continue" 
implementation. I would like to get comments about this idea and 
eventually suggestions about the possible implementation.

Thanks,

tito.
---------------------------
Let's say our users are classified in two overlapping groups: group1 
including user1 and user2, and group2 including user2 and user3.

Each group can get access to the URLs identified by the destination 
dest1 (for group1) and dest2 (for group2).

It would be intuitive to implement a squidguard configuration like this:

acl {
       group1 {
               pass     dest1
       }
       group2 {
               pass     dest2
       }
       default {
               pass     !blocked any
               redirect http://127.0.0.1:80/cgi-bin/blocked
       }
}

Unfortunately this doesn't do what we need. Let's consider a couple of 
examples:

a) user1 accessing to dest1: user1 is in group1 and should pass
b) user1 accessing to dest2: user1 is not in group2 and should be blocked

The result of the above configuration is that:

- case a) is ok, the access is allowed as it should
- case b) is not ok, the access is allowed and it should not

In alternative, we could use the "continue" option for the group1 
source. So doing:

- case b) is ok, the access is denied, as it should
- case a) is not ok, the access is also denied, because it is 
"continued" to the default rule.

As a third alternative I could define group1 as follows:

group1 {
               pass     dest1  none
      }

In this case, both a) and b) would be ok, but user2 access to dest2 
would be blocked by this rule. Instead it should be allowed, due to the 
group2 rule, because user2 is also included in group2.

A possible solution to implement this scenario is to change the 
"continue" behavior, to go on examining other rules if the destination 
do not match.




Reply via email to