[Freeswitch-dev] Difference of behaviour between apply-acl profile parameters
Florent Krieg
fkrieg at sewan.eu
Wed Mar 12 20:48:30 MSK 2014
Anthony, all,
I wrote a fix this afternoon based on a git master pull (which compiles
and works like a charm after some tests).
As I haven't done C programming in ages hence I'd be very grateful if
one of you could tell me if the patch is very unstable/could cause a lot
of troubles, and so on.
Here it is:
[user at vm ~]# diff
/root/freeswitch/src/mod/endpoints/mod_sofia/mod_sofia.h
/root/freeswitch_git_test/freeswitch/src/mod/endpoints/mod_sofia/mod_sofia.h
952c952
< uint8_t sofia_reg_handle_register_sw(nua_t *nua, sofia_profile_t
*profile, nua_handle_t *nh, sip_t const *sip,
---
> uint8_t sofia_reg_handle_register(nua_t *nua, sofia_profile_t
*profile, nua_handle_t *nh, sip_t const *sip,
955,956c955
< uint32_t keylen, switch_event_t **v_event, const char *is_nat,
sofia_private_t **sofia_private_p, switch_xml_t *user_xml, char
*sw_acl_token);
< #define sofia_reg_handle_register(_nua_, _profile_, _nh_, _sip_,
_de_, _regtype_, _key_, _keylen_, _v_event_, _is_nat_,
_sofia_private_p_, _user_xml_) sofia_reg_handle_register_sw(_nua_,
_profile_, _nh_, _sip_, _de_, _regtype_, _key_, _keylen_, _v_event_,
_is_nat_, _sofia_private_p_, _user_xml_, NULL)
---
> uint32_t keylen, switch_event_t **v_event, const char *is_nat,
sofia_private_t **sofia_private_p, switch_xml_t *user_xml);
[user at vm ~]# diff
/root/freeswitch/src/mod/endpoints/mod_sofia/sofia_reg.c
/root/freeswitch_git_test/freeswitch/src/mod/endpoints/mod_sofia/sofia_reg.c
1119c1119
< uint8_t sofia_reg_handle_register_sw(nua_t *nua, sofia_profile_t
*profile, nua_handle_t *nh, sip_t const *sip,
---
> uint8_t sofia_reg_handle_register(nua_t *nua, sofia_profile_t
*profile, nua_handle_t *nh, sip_t const *sip,
1121c1121
< uint32_t keylen, switch_event_t **v_event, const char *is_nat,
sofia_private_t **sofia_private_p, switch_xml_t *user_xml, char
*sw_acl_token)
---
> uint32_t keylen, switch_event_t **v_event, const char *is_nat,
sofia_private_t **sofia_private_p, switch_xml_t *user_xml)
1176,1179d1175
< // FK
< char *sw_to_user;
< char *sw_reg_host;
<
1405,1410d1400
< // FK
< if (sw_acl_token) {
< switch_split_user_domain(sw_acl_token, &sw_to_user, &sw_reg_host);
< to_user = sw_to_user;
< reg_host = sw_reg_host;
< }
2080,2081d2069
< // FK
< char acl_token[512] = "";
2159,2160d2146
< // FK
< const char *token_sw = NULL;
2164c2150
< if (!(ok =
switch_check_network_list_ip_token(network_ip, last_acl, &token_sw))) {
---
> if (!(ok =
switch_check_network_list_ip(network_ip, last_acl))) {
2171,2173d2156
< if (token_sw) {
< switch_set_string(acl_token, token_sw);
< }
2194c2177
< sofia_reg_handle_register_sw(nua, profile, nh, sip, de,
type, key, sizeof(key), &v_event, is_nat, sofia_private_p, NULL,
acl_token);
---
> sofia_reg_handle_register(nua, profile, nh, sip, de, type,
key, sizeof(key), &v_event, is_nat, sofia_private_p, NULL);
I don't mean it to be integrated into FS core, if you don't want it to be.
I am just willing to use it for our platform and would like your advices
because I am not very confident about the dev done.
Thanks all in advance!
Florent
Le 12/03/2014 17:11, Florent Krieg a écrit :
> Hello Anthony,
>
> Actually we only use the domains acl (I am not even sure what is 'real
> acl', we only use it in correlaton with cidr users' fields),
> automatically generated by scanning the user directory (we are in a
> multi-homed environment).
> Here is an example (taken out from the logs):
>
> switch_utils.c:324 Adding XXX.XXX.XXX.XXX/32 (allow)
> [account at test] to list domains
>
> With 'apply-inbound-acl=domains' and 'apply-register-acl=domains',
> when XXX.XXX.XXX.XXX tries to register with a random login at domain (eg:
> alice at alice, account which doesn't exist at all, assuming we only have
> 'account at test') to our platform, it goes OK.
> If we do a 'sofia_contact alice at alice', it returns the register from
> the db.
>
> Now:
> * if we start a call, it will be authentified as 'account at test' (which
> is OK)
> * if we receive a call, we won't be able to get the contact for
> 'account at test' because the record in db is (to_user=)alice and
> (reg_host=)alice
> So in the last case we have to do static routing. We want to avoid it
> as much as possible.
>
>
> I am not sure whether I am clear...
> Regards,
> Florent
>
>
> Le 12/03/2014 15:42, Anthony Minessale a écrit :
>> apply-register acl is specifically designed to be used with the
>> "domains" acl which is automatically generated by scanning the user
>> directory and building a list using the cidr field and tokenizing the
>> user to match the range of each acl entry. Its not really useful
>> with normal acl's.
>>
>>
>> On Wed, Mar 12, 2014 at 8:23 AM, Florent Krieg <fkrieg at sewan.eu
>> <mailto:fkrieg at sewan.eu>> wrote:
>>
>> I forgot the part of sofia.c that does switch user, please find
>> it inlined below.
>>
>> Le 12/03/2014 14:03, Florent Krieg a écrit :
>>> Hello all,
>>>
>>> While checking and tuning our FreeSWITCH configuration, I found
>>> out that there is big difference of behaviour between the
>>> apply-inbound-acl and apply-register-acl sofia sip profile
>>> parameters.
>>> => in the case of 'apply-inbound-acl', requests coming from an
>>> IP present in the acl profile list will be authentified as the
>>> matching account, which is OK.
>>> => in the case of 'apply-register-acl', register requests coming
>>> from an IP present in the acl profile list will be authorized
>>> (which is OK), while being 'authentified' as the user specified
>>> in the SIP request. I would have imagined that register requests
>>> would be identified as the matching account as well. We end up
>>> in getting crazy registrations (devices registered as user not
>>> existing in the directory for instance), when customers'
>>> hardware are not permissive enough to allow from (user at domain)
>>> field customisation (while outgoing calls are perfectly working).
>>>
>>> Is that behaviour wanted by the community?
>>>
>>> I checked the source code which I reckon I am not familiar with
>>> at all, and I found that:
>>> * apply-inbound-acl (sofia.c):
>>>
>>> if (profile->acl_count) {
>>> uint32_t x = 0;
>>> int ok = 1;
>>> char *last_acl = NULL;
>>> const char *token = NULL;
>>>
>>> for (x = 0; x < profile->acl_count; x++) {
>>> last_acl = profile->acl[x];
>>> if ((ok =
>>> switch_check_network_list_ip_token(network_ip, last_acl,
>>> &token))) {
>>>
>>> if
>>> (profile->acl_pass_context[x]) {
>>> acl_context = profile->acl_pass_context[x];
>>> }
>>>
>>> break;
>>> }
>>>
>>> if (profile->acl_fail_context[x]) {
>>> acl_context = profile->acl_fail_context[x];
>>> } else {
>>> acl_context = NULL;
>>> }
>>> }
>>>
>>> if (ok) {
>>> if (token) {
>>> switch_set_string(acl_token, token);
>>> }
>>> if (sofia_test_pflag(profile,
>>> PFLAG_AUTH_CALLS)) {
>>> switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_DEBUG, "IP
>>> %s Approved by acl \"%s[%s]\". Access Granted.\n",
>>> network_ip, switch_str_nil(last_acl), acl_token);
>>> switch_set_string(sip_acl_authed_by, last_acl);
>>> switch_set_string(sip_acl_token, acl_token);
>>> is_auth = 1;
>>> }
>>>
>> [...]
>>
>> if (*acl_token) {
>> switch_channel_set_variable(channel, "acl_token", acl_token);
>> if (strchr(acl_token, '@')) {
>> if (switch_ivr_set_user(session,
>> acl_token) == SWITCH_STATUS_SUCCESS) {
>> switch_log_printf(SWITCH_CHANNEL_SESSION_LOG(session),
>> SWITCH_LOG_DEBUG, "Authenticating user %s\n", acl_token);
>> } else {
>> switch_log_printf(SWITCH_CHANNEL_SESSION_LOG(session),
>> SWITCH_LOG_WARNING, "Error Authenticating user %s\n", acl_token);
>> }
>> }
>> }
>>
>>
>>> * apply-register-acl (sofia_reg.c):
>>>
>>> if (profile->reg_acl_count) {
>>> uint32_t x = 0;
>>> int ok = 1;
>>> char *last_acl = NULL;
>>>
>>> for (x = 0; x < profile->reg_acl_count; x++) {
>>> last_acl = profile->reg_acl[x];
>>> if (!(ok =
>>> switch_check_network_list_ip(network_ip, last_acl))) {
>>> break;
>>> }
>>> }
>>>
>>> if (ok && !sofia_test_pflag(profile,
>>> PFLAG_BLIND_REG)) {
>>> type = REG_AUTO_REGISTER;
>>>
>>>
>>> Is what I expect (similar behaviour in both cases) crazy to you?
>>> Or does it sound right?
>>>
>>> In the latter case, should I open a JIRA case for somebody to
>>> push a fix?
>>> I could try to 'fix' it myself (in case you consider it as a bug
>>> as I do) but I am not really familiar with C development as well.
>>>
>>> Thank for your points of view!
>>> Regards
>>> Florent
>>>
>>>
>>> _________________________________________________________________________
>>> Professional FreeSWITCH Consulting Services:
>>> consulting at freeswitch.org <mailto:consulting at freeswitch.org>
>>> http://www.freeswitchsolutions.com
>>>
>>>
>>>
>>>
>>> Official FreeSWITCH Sites
>>> http://www.freeswitch.org
>>> http://wiki.freeswitch.org
>>> http://www.cluecon.com
>>>
>>> FreeSWITCH-dev mailing list
>>> FreeSWITCH-dev at lists.freeswitch.org <mailto:FreeSWITCH-dev at lists.freeswitch.org>
>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
>>> http://www.freeswitch.org
>>
>>
>> _________________________________________________________________________
>> Professional FreeSWITCH Consulting Services:
>> consulting at freeswitch.org <mailto:consulting at freeswitch.org>
>> http://www.freeswitchsolutions.com
>>
>>
>>
>>
>> Official FreeSWITCH Sites
>> http://www.freeswitch.org
>> http://wiki.freeswitch.org
>> http://www.cluecon.com
>>
>> FreeSWITCH-dev mailing list
>> FreeSWITCH-dev at lists.freeswitch.org
>> <mailto:FreeSWITCH-dev at lists.freeswitch.org>
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
>> http://www.freeswitch.org
>>
>>
>>
>>
>> --
>> Anthony Minessale II ? @anthmfs ? @FreeSWITCH ?
>>
>> ? http://freeswitch.org/ ? http://cluecon.com/ ?
>> http://twitter.com/FreeSWITCH
>> ? irc.freenode.net <http://irc.freenode.net> #freeswitch ?
>> _http://freeswitch.org/g+_
>>
>> ClueCon Weekly Development Call
>> ? sip:888 at conference.freeswitch.org
>> <mailto:sip%3A888 at conference.freeswitch.org> ? +19193869900
>>
>>
>>
>> _________________________________________________________________________
>> Professional FreeSWITCH Consulting Services:
>> consulting at freeswitch.org
>> http://www.freeswitchsolutions.com
>>
>>
>>
>>
>> Official FreeSWITCH Sites
>> http://www.freeswitch.org
>> http://wiki.freeswitch.org
>> http://www.cluecon.com
>>
>> FreeSWITCH-dev mailing list
>> FreeSWITCH-dev at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
>> http://www.freeswitch.org
>
>
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
>
>
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-dev mailing list
> FreeSWITCH-dev at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20140312/c6752a63/attachment-0001.html
Join us at ClueCon 2013 Aug 6-8, 2013
More information about the FreeSWITCH-dev
mailing list