Duplicate "object" definition
Hi all, I apologize if I don't use the right terminology. I'm playing/testing with 3.2.6 to better understand how freeradius behaves when finding duplicate definitions. I created a copy of the filter policy, calling it policy.d/filter2 and I defined the object/policy filter_username in this way: filter_username { if (&User-Name) { reject } } Now, when in the directory policy.d I only have the file filter2, I always get the expected Access-Reject, if I just have the default file filter I get Access-Accept (the user is correctly configured in the file users). If I have both files (filter and filter 2), when I launch radiusd -X I get, the file filter is loaded first and then the file filter2 ... *including configuration file /etc/freeradius/policy.d/filter <<<*including configuration file /etc/freeradius/policy.d/operator-name including configuration file /etc/freeradius/policy.d/eap including configuration file /etc/freeradius/policy.d/debug including configuration file /etc/freeradius/policy.d/accounting *including configuration file /etc/freeradius/policy.d/filter2 <<<* ... and I always get Access-Accept. How are duplicate objects treated? Is the first definition that's retained or the last? From my experiment it seems the first is retained. May you please confirm? Regards, Alex
The radius config parser will not load a duplicate named routine. You would need to change the name and then add a call to it either before or after the original routine call/s. However, if you are looking to see if a User-Name attribute exists, and then reject it if it does, your routine, when added will do it. Duplicate checking is handled in the sites-available configs, which you can either enable or disable. If you are using a database, then the sql code is included and can be used. Please read the instructions found in the config files for guidance. Thanks On 2024/11/03 23:05, Alex Zetaeffesse wrote:
Hi all,
I apologize if I don't use the right terminology. I'm playing/testing with 3.2.6 to better understand how freeradius behaves when finding duplicate definitions. I created a copy of the filter policy, calling it policy.d/filter2 and I defined the object/policy filter_username in this way:
filter_username { if (&User-Name) { reject } }
Now, when in the directory policy.d I only have the file filter2, I always get the expected Access-Reject, if I just have the default file filter I get Access-Accept (the user is correctly configured in the file users). If I have both files (filter and filter 2), when I launch radiusd -X I get, the file filter is loaded first and then the file filter2
...
*including configuration file /etc/freeradius/policy.d/filter <<<*including configuration file /etc/freeradius/policy.d/operator-name including configuration file /etc/freeradius/policy.d/eap including configuration file /etc/freeradius/policy.d/debug including configuration file /etc/freeradius/policy.d/accounting
*including configuration file /etc/freeradius/policy.d/filter2 <<<* ...
and I always get Access-Accept. How are duplicate objects treated? Is the first definition that's retained or the last? From my experiment it seems the first is retained. May you please confirm?
Regards,
Alex - List info/subscribe/unsubscribe? Seehttp://www.freeradius.org/list/users.html
On Nov 3, 2024, at 9:05 PM, Alex Zetaeffesse <fzetafs@gmail.com> wrote:
I'm playing/testing with 3.2.6 to better understand how freeradius behaves when finding duplicate definitions.
I'm not sure why this is important, but OK.
I created a copy of the filter policy, calling it policy.d/filter2 and I defined the object/policy filter_username in this way: .. Now, when in the directory policy.d I only have the file filter2, I always get the expected Access-Reject, if I just have the default file filter I get Access-Accept (the user is correctly configured in the file users). If I have both files (filter and filter 2), when I launch radiusd -X I get, the file filter is loaded first and then the file filter2
Yes.
How are duplicate objects treated? Is the first definition that's retained or the last? From my experiment it seems the first is retained. May you please confirm?
You've tested it's behavior, and verified how it works. I'm not sure that there's much to confirm. If you think this is a bug, then we're happy to accept a patch which fixes this. If this isn't a bug, then the behavior is fine. Alan DeKok.
"You've tested its behavior, and verified how it works. I'm not sure that there's much to confirm. If you think this is a bug, then we're happy to accept a patch which fixes this. If this isn't a bug, then the behavior is fine. I do agree that I'm pushing a bit freeradius, I'm fine with its behaviour, I just wanted to be sure in case by mistake a define two functions with the same name (again, I'm speaking about mistakes, that may happen when you test things). Thanks Conrad and Alan, Alex On Mon, Nov 4, 2024 at 10:07 AM Alan DeKok <aland@deployingradius.com> wrote:
On Nov 3, 2024, at 9:05 PM, Alex Zetaeffesse <fzetafs@gmail.com> wrote:
I'm playing/testing with 3.2.6 to better understand how freeradius behaves when finding duplicate definitions.
I'm not sure why this is important, but OK.
I created a copy of the filter policy, calling it policy.d/filter2 and I defined the object/policy filter_username in this way: .. Now, when in the directory policy.d I only have the file filter2, I always get the expected Access-Reject, if I just have the default file filter I get Access-Accept (the user is correctly configured in the file users). If I have both files (filter and filter 2), when I launch radiusd -X I get, the file filter is loaded first and then the file filter2
Yes.
How are duplicate objects treated? Is the first definition that's retained or the last? From my experiment it seems the first is retained. May you please confirm?
You've tested it's behavior, and verified how it works. I'm not sure that there's much to confirm.
If you think this is a bug, then we're happy to accept a patch which fixes this. If this isn't a bug, then the behavior is fine.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (3)
-
Alan DeKok -
Alex Zetaeffesse -
Conrad Classen