<!-- Kamailio Pull Request Template -->
<!-- IMPORTANT: - for detailed contributing guidelines, read: https://github.com/kamailio/kamailio/blob/master/.github/CONTRIBUTING.md - pull requests must be done to master branch, unless they are backports of fixes from master branch to a stable branch - backports to stable branches must be done with 'git cherry-pick -x ...' - code is contributed under BSD for core and main components (tm, sl, auth, tls) - code is contributed GPLv2 or a compatible license for the other components - GPL code is contributed with OpenSSL licensing exception -->
#### Pre-Submission Checklist <!-- Go over all points below, and after creating the PR, tick all the checkboxes that apply --> <!-- All points should be verified, otherwise, read the CONTRIBUTING guidelines from above--> <!-- If you're unsure about any of these, don't hesitate to ask on sr-dev mailing list --> - [x] Commit message has the format required by CONTRIBUTING guide - [x] Commits are split per component (core, individual modules, libs, utils, ...) - [x] Each component has a single commit (if not, squash them into one commit) - [x] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated)
#### Type Of Change - [x] Small bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality)
#### Checklist: <!-- Go over all points below, and after creating the PR, tick the checkboxes that apply --> - [ ] PR should be backported to stable branches - [x] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number)
#### Description <!-- Describe your changes in detail -->
This PR allows the functions `allow_address_group` and `allow_source_address_group` to search for Longest Prefix Match (LPM) when searching for an IP is in a subnet instead of the first found.
Since this is a stricter check, i don't think we require an extra param for it, but feel free to suggest otherwise if there are any use-cases that required the first matched. You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/4297
-- Commit Summary --
* permissions: Perform LPM to find the longest matching subnet
-- File Changes --
M src/modules/permissions/hash.c (23)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/4297.patch https://github.com/kamailio/kamailio/pull/4297.diff
miconda left a comment (kamailio/kamailio#4297)
It is a stricter check, but still changing the existing behaviour, so I am not sure what would be the best. Personally I don't think that I am affected, I don't remember having need to have records of overlapping subnets, but maybe there are others that are affected, so they have to comment.
My concern comes from another perspective, whether now the behaviour is consistent with the matching a subnet record with `allow_[source_]address()`. If one has overlapping subnets in the same group, will the same record as `allow_[source_]address_group()` be matched? Even I don't have it so far, one reason I could think of right now to have overlapping subnets is to return different values from the tag column.
So whatever mode it ends up with, new parameter or not, matching should be coherent across the module functions.
@xkaraman pushed 1 commit.
94d077e84da94b3293f77d7475401282f33f464a permissions: Perform LPM to find the longest matching subnet
xkaraman left a comment (kamailio/kamailio#4297)
@miconda Thanks for the review!
Indeed, the `allow_source_address` could return a different tag value with this approach! So with the new commit a similar LPM is performed to verify whether is in that group for overlapping domains!
We confirmed that now, both functions return the same tag!
miconda left a comment (kamailio/kamailio#4297)
I am fine to merge it, but a note has to be added in the docs for the affected functions to be clear how the matching is done with this commit.
@xkaraman pushed 2 commits.
703694a4a69cbcc51c4c1850e83e9ea970d763b7 permissions: Perform LPM to find the longest matching subnet 21c05e26e0a22d2df6e792cc605280d47e440535 permissions: doc: Add note related to LPM search
xkaraman left a comment (kamailio/kamailio#4297)
@miconda
Added notes regarding the search in the 4 related functions.
miconda left a comment (kamailio/kamailio#4297)
The note seems to be for `allow_[source_]address_group()` because it says `which was previously the entry with the lowest group ID`. For `allow_[source_]address()`, the matching is within same group, but still can be different network prefixes. Maybe that parenthesis should be removed or clarified is for the get-the-group functions.
I also see you mentioned the version 6.0.3, I am not sure about backporting, is it considered a bug fix? I guess this has to be discussed in a larger group. Or add a mod param, defaulting to old behaviour and backport in 6.0 and then switch to the new behaviour in 6.1, so nobody has unexpected surprises after upgrading within 6.0.x series in the future.
Also, instead of having the note for each function, maybe is better added to the section at the top about address permissions:
- https://www.kamailio.org/docs/modules/stable/modules/permissions.html#sec-ad...
miconda left a comment (kamailio/kamailio#4297)
Thinking more about it, a modparam would be good to have anyhow, because the PR has also impact on performance.
Instead of returning on first match, now all the records are tried always, so, for example, even when the match would be the 1st or the 10th within 100 records, all the 100 records are tried to see if there is a longer match.
xkaraman left a comment (kamailio/kamailio#4297)
The note seems to be for `allow_[source_]address_group()` because it says `which was previously the entry with the lowest group ID`. For `allow_[source_]address()`, the matching is within same group, but still can be different network prefixes. Maybe that parenthesis should be removed or clarified is for the get-the-group functions.
Ah good catch, yes i should clarify that about the group variants.
I also see you mentioned the version 6.0.3, I am not sure about backporting, is it considered a bug fix? I guess this has to be discussed in a larger group. Or add a mod param, defaulting to old behaviour and backport in 6.0 and then switch to the new behaviour in 6.1, so nobody has unexpected surprises after upgrading within 6.0.x series in the future.
No, not a bug fix. Just confused and wrote it for the next release, but didn't consider if its a bug. I will change to 6.1.x or maybe remove it completerly.
Also, instead of having the note for each function, maybe is better added to the section at the top about address permissions:
Hmm, yeah could do it there as well, but will it be read if someone goes directly to the function doc? Maybe if i add link to it as the note in functions.
Thinking more about it, a modparam would be good to have anyhow, because the PR has also impact on performance.
Instead of returning on first match, now all the records are tried always, so, for example, even when the match would be the 1st or the 10th within 100 records, all the 100 records are tried to see if there is a longer match.
Yeah that's true. Not sure if it's noticable in that range of records, but for a lot more it might be a problem.
@xkaraman pushed 2 commits.
acb9a7d4fd0d92ec26734ed77d8694002ea0dd61 permissions: Perform LPM to find the longest matching subnet 470bc3dda0a165a795388d8a30c790e5be4459f4 permissions: doc: Add note related to LPM search
xkaraman left a comment (kamailio/kamailio#4297)
@miconda Docs updated. are these better?
Merged #4297 into master.
henningw left a comment (kamailio/kamailio#4297)
Merged, thanks. Further adaptions can be done in git master if necessary.
miconda left a comment (kamailio/kamailio#4297)
For the records, I added a new module parameter `subnet_match_mode` to control if the subnet matching is on first prefix or longest prefix, it feels unnecessary to match always all the records when usually is a single match. The default is first prefix match to ensure backward compatibility and don't affect deployments on upgrade.