[asterisk-dev] AstriDevCon - PineMango

Nir Simionovich nir.simionovich at gmail.com
Thu Oct 9 16:04:33 CDT 2008

This is becoming a very interesting thread, but I'm getting the feeling 
we would be required to split this thread into two in a short time.

bmd wrote:
>To clarify, we're talking about fine-grained auth here, not the yes/no
>type in a password to use the API socket.  We currently don't
>authenticate AGI scripts, cli commands, dialplan scripts, and manager's
>security model is a joke.

>Meanwhile, to properly do the security we're talking about would involve
>passing ownership credentials around in every ast_chan structure, every
>event, every *_pvt and peer structure, as well as every dialplan switch.

>Finally, both Jay Phillips and I agree that the auth mechanism can be
>implemented at the framework layer.  Take a look at Switchvox's
>fine-grained permissions structures as an example of auth done higher up
>the stack:


Hmmm... you've brought up an interesting point. I agree that going about
and adding AA abilities to each structure, event, pvt, etc in the Asterisk
core is a highly ambitious task to undertake - however, the question that 
still remains unanswered is: "Is this the right way to go?" 

I agree that having such level of control over the Asterisk core would be
as close to Asterisk godly hood, however, I'm not entirely sure that this
level is required in such fine granularity. I do believe that providing 
an AA layer that would be able to utilize a pluggable configuration
mechanism, which defines the granularity will be just as good. I don't 
believe that going about and attaching AA abilities to each configuration
object is the right way to do this - maybe the solution is somewhere in
between the methodologies?

>While it would be nice to be able to partition an asterisk instance into
>two halves that cannot access each other:
>a) we can't do that now, but we seem to manage.

We manage, that is true. But that level of manageability is still considered
a myth for most Asterisk users/application developers (application meaning 
as voice application, not Asterisk application). This knowledge is currently
kept under closed doors with people who make a $$$ out of it. 

>b) the development effort is massive.

True, nough said there.

>c) running asterisk in virtualization or just running two processes is
>almost just as good.

Hmmm... Highly dependent on the usage! I've got customers running Asterisk
with VMWARE and XEN, each one for different purposes, the performance varies
to an extent that it can't even be compared. 

/Nir S

More information about the asterisk-dev mailing list