attr_filter rule evaluation
Hi!
From the documentation I find it a little bit confusing how filter rules work exactly.
The manual page rlm_attr_filter says: "The rules for each entry are parsed to top to bottom, and an attribute must pass *all* the rules which affect it in order to make it past the filter." The post-proxy file contains this: DEFAULT Service-Type == Framed-User, Service-Type == Login-User, Login-Service == Telnet, Login-Service == Rlogin, Login-Service == TCP-Clear, Login-TCP-Port <= 65536, ... But if it has to pass all the rules doesn't that mean that Service-Type and Login-Service are basically always filtered out because, for instance, for a single valued Service-Type attribute either the first or second rule will always fail. And as there is always one rule failing it will never make it past the filter. Thanks, Gerald
On Apr 22, 2015, at 7:19 AM, Gerald Vogt <vogt@spamcop.net> wrote:
From the documentation I find it a little bit confusing how filter rules work exactly.
It's pretty simple. Unfortunately simple, in fact.
The post-proxy file contains this:
DEFAULT Service-Type == Framed-User, Service-Type == Login-User, Login-Service == Telnet, Login-Service == Rlogin, Login-Service == TCP-Clear, Login-TCP-Port <= 65536, ...
But if it has to pass all the rules doesn't that mean that Service-Type and Login-Service are basically always filtered out because, for instance, for a single valued Service-Type attribute either the first or second rule will always fail. And as there is always one rule failing it will never make it past the filter.
Yes. If you want more complex filtering, use unlang. Alan DeKok.
On 22.04.15 13:53, Alan DeKok wrote:
On Apr 22, 2015, at 7:19 AM, Gerald Vogt <vogt@spamcop.net> wrote:
The post-proxy file contains this:
DEFAULT Service-Type == Framed-User, Service-Type == Login-User, Login-Service == Telnet, Login-Service == Rlogin, Login-Service == TCP-Clear, Login-TCP-Port <= 65536, ...
But if it has to pass all the rules doesn't that mean that Service-Type and Login-Service are basically always filtered out because, for instance, for a single valued Service-Type attribute either the first or second rule will always fail. And as there is always one rule failing it will never make it past the filter.
Yes.
If you want more complex filtering, use unlang.
I don't need more complex filtering. But it would help if the files installed would contain some useful examples. If that DEFAULT entry just filters out any Service-Type and Login-Service attribute then that's not what I would expect from seeing this in an unmodified file distributed from the source. So may I suggest that the post-proxy file only contains actually useful and working examples.
From the above lines I would assume it means accept Service-Type Framed-User or Login-User but filter any other value.
There is also a commented out example which doesn't make sense then: # These rules allow: # o Only Login-User Service-Type ( no framed/ppp sessions ) # o Telnet sessions only ( no rlogin, tcp-clear ) # o Login hosts of either 192.0.2.1 or 192.0.2.2 # #tisp # Service-Type == Login-User, # Login-Service == Telnet, # Login-TCP-Port == 23, # Login-IP-Host == 192.0.2.1, # Login-IP-Host == 192.0.2.2 Whatever Login-IP-Host may be it will always be filtered out so actually it does not do what the description before says... Thanks, Gerald
On Apr 22, 2015, at 9:26 AM, Gerald Vogt <vogt@spamcop.net> wrote:
I don't need more complex filtering. But it would help if the files installed would contain some useful examples. If that DEFAULT entry just filters out any Service-Type and Login-Service attribute then that's not what I would expect from seeing this in an unmodified file distributed from the source.
Sure.
So may I suggest that the post-proxy file only contains actually useful and working examples.
In these situations, I may suggest sending a patch via github. Pointing out a problem is nice. Giving a fix is MUCH nicer. Alan DeKok.
On 22.04.15 16:29, Alan DeKok wrote:
On Apr 22, 2015, at 9:26 AM, Gerald Vogt <vogt@spamcop.net> wrote:
So may I suggest that the post-proxy file only contains actually useful and working examples.
In these situations, I may suggest sending a patch via github.
Pointing out a problem is nice. Giving a fix is MUCH nicer.
Generally, I agree with you but in this case I hardly know enough to what the filters really can do and what not to describe them accurately or how to modify that filter rules to accept what it currently suggests: accept Service-Type Framed-User or Login-User or accept Login-IP-Host 192.0.2.1 or 192.0.2.2. I guess it is possible with a regular expression. And I guess you already know how to write that down while I would have to carefully try and test it to find out how it's really done... Thanks, Gerald
participants (2)
-
Alan DeKok -
Gerald Vogt