On Thu, 17 Oct 2002, Tito Flagella wrote:
> 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.
I'm sure this is not the kind of feedback that you were expecting,
but I believe that you should be seeing different results than those
you listed in your example. See my in-line [comments] below.
> ---------------------------
> 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
> }
[If you only want to allow dest1 it should read 'pass dest1 none']
> group2 {
> pass dest2
> }
[If you only want to allow dest2 it should read 'pass dest2 none']
> default {
> pass !blocked any
> redirect http://whatever/cgi-bin/blocked> }
> }
[You are restricting users that are listed in your source definitions
to pre-approved site lists, but you are allowing unknown users (not
defined in source definitions) to go to _any_ site that is not
specifically 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
[That's not the way it works; something is wrong. Try adding the
'none' in your acl as recommened above. user1 is only a member of
group1 and shouldn't be approved for a site that is not in dest1.]
[If squidGuard is in emergency mode it will approve everything; the
squidGuard.log will tell you that.]
[Is the user identification working properly all the way into
squidGuard? (You can find that out by adding log statements to your
destination groups.) If squidGuard was unable to identify the user,
your current configuration would allow him to go anywhere that is
not specifically blocked.]
[user2 is a member of 2 groups and there would be another factor
to consider if we were talking about user2. If group1 is defined
before group2, and the continue option is *not* used, user2 will
*always* be handled as a member of group1; *never* handled as a
member of group2.]
Does that satisfy your issues?
Rick Matthews
