Hi Rick,
thanks for your reply.
On Thu, 17 Oct 2002, Rick Matthews wrote:
> > 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.]
>
Yes. As I told in my original message (it was exposed as the thirdh
alternative), when I use the 'none' option, both a) and b) work as
expected.
But, in this case, user2 access to dest2 will be blocked by the
group1 rule. Instead it should be allowed, due to the group2 rule,
because user2 is also included in group2.
You correctly say:
[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.]
But, actually, user2 will be *never* considered as a member of group2,
also when the continue option is used. This because user2 has been
blocked by the group1 rule, and continue works *only* if user has *not*
been blocked.
That's why I say it would be better to go on examining other rules also in
the case the client would have been blocked, but the destination
do not match. Or in other words, we need to have the possibility to say:
pass dest all
pass dest none
or
pass dest continue
tito.
