[Asterisk-code-review] res_rtp_asterisk: implement ACL mechanism for ICE and STUN addresses. (asterisk[13])

[Jaco Kroon]

Jaco Kroon has posted comments on this change. ( https://gerrit.asterisk.org/c/asterisk/+/13309 )

Change subject: res_rtp_asterisk: implement ACL mechanism for ICE and STUN addresses.
......................................................................


Patch Set 4:

(3 comments)

https://gerrit.asterisk.org/c/asterisk/+/13309/4/res/res_rtp_asterisk.c 
File res/res_rtp_asterisk.c:

https://gerrit.asterisk.org/c/asterisk/+/13309/4/res/res_rtp_asterisk.c@2987 
PS4, Line 2987: 		if ((val = ast_variable_retrieve(cfg, section, opt))) {
> There can be multiple acl/deny/permit/blacklist specified, doesn't this fail under that scenario by  […]
I'll investigate but I believe you may be right.


https://gerrit.asterisk.org/c/asterisk/+/13309/4/res/res_rtp_asterisk.c@2994 
PS4, Line 2994: 	if (acl_subscription_flag && !acl_change_sub) {
> If no ACLs are configured does it make sense to not have this subscription occur?
int acl_subscription_flag = 0;

This flag will only be set by ast_append_acl if it believes we should subscribe (ie, we're referencing a named ACL).  So I believe this code is correct.


https://gerrit.asterisk.org/c/asterisk/+/13309/4/res/res_rtp_asterisk.c@6898 
PS4, Line 6898: 	rtp_reload(1, 1);
> Can't you just call rtp_load_acl for each?
This mechanism was cloned from elsewhere (Think manager.c but I'm not certain).  Basically, if rtp.conf changes the reload will happen.  If a named ACL changes, we don't have a reference on which names we're supposed to be referencing.

Ideally actually I'd like this entire subscribe to not be required, in that if a named ACL is referenced, the ACL infrastructure itself would be aware of that, and update the referencing parties by implication.  Should I perhaps investigate if that would be possible?

As an aside since this would be related, is the aim of acl to match most-specific match, or last match?

Eg:

permit = 1.2.3.4/32
deny = 0.0.0.0/0

Should 1.2.3.4 be permitted or denied?



-- 
To view, visit https://gerrit.asterisk.org/c/asterisk/+/13309
To unsubscribe, or for help writing mail filters, visit https://gerrit.asterisk.org/settings

Gerrit-Project: asterisk
Gerrit-Branch: 13
Gerrit-Change-Id: Id57a8df51fcfd3bd85ea67c489c85c6c3ecd7b30
Gerrit-Change-Number: 13309
Gerrit-PatchSet: 4
Gerrit-Owner: Jaco Kroon <jaco at uls.co.za>
Gerrit-Reviewer: Friendly Automation
Gerrit-Reviewer: Joshua C. Colp <jcolp at digium.com>
Gerrit-Comment-Date: Thu, 12 Dec 2019 09:52:21 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: Joshua C. Colp <jcolp at digium.com>
Gerrit-MessageType: comment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-code-review/attachments/20191212/af9d68a5/attachment-0001.html>