[Asterisk-Dev] New manager API command

[Steven Critchfield]

On Wed, 2005-11-09 at 10:04 -0700, Saul Diaz wrote:
> snacktime wrote:
> 
> >
> >
> > On 11/8/05, *Saul Diaz* <saul at cripiland.com 
> > <mailto:saul at cripiland.com>> wrote:
> >
> >     Hi
> >
> >     i am think in build a manager APPL for retrieve files (recordings,
> >     voicemails) from the asterisk through the manager API
> >
> >     something like GETFILE <FILENAME> will be restricted to a particulars
> >     folders /var/spool/asterisk related... so u can get files from
> >     monitor
> >     or voicemail but don't compromise your server
> >
> >
> > IMO this example really isn't an asterisk specific feature.  It's a 
> > way to transfer files from one server to another.  The fact that it's 
> > files in the asterisk directory you want to transfer is really 
> > secondary.  Plus as Matt pointed out there are so many different ways 
> > to do this, and different people will want it done differently.  For 
> > example I do this using a really simple distributed ruby proxy that 
> > gives me a remote file handle I can read or write to.  I use it to 
> > stream voicemail files from the asterisk server to the webserver and 
> > on to end users.  You could also run a chrooted ftp server or use scp. 
> >
> That's was part of the question in the email.. is really more stress for 
> an asterisk server put a ruby proxy or webserver in busy server?
> 
> first scenario that come to my mind.. you have a manager appl allowing 
> ppl to to monitor your asterisk server (i already have that 
> http://www.cripiland.com/screenshots/manager3.jpg) a suppervisor wants 
> to hear the recorders for the phones...or hear his voicemail in his viewver!
> 
> for everything that u say u have to install another server in the 
> aterisk ftp server, webserver.. how much stress this bring to a busy 
> asterisk compared with just an action to uuencode the file and send it?

While I know the developers here are very conscientious about their
programming and do their best to not introduce any exploitable bugs, but
your asking for a pretty big feature add. It has to be protected,
secured, and constantly tested to make sure it doesn't expose anything
that would compromise the machine. 

I would suggest following the unix tools philosophy and put file
transports in a separate tool that does that, that alone, and does it
well. It also will allow you to tune it separately than asterisk even to
the point of swapping out the app that serves the file up.

Consider the potential for exploit if the file serving could take down
the rest of your asterisk install due to running in the same memory
space.

As this is just my opinion that it doesn't belong in the manager
interface, if it does get considered, please allow it to be ifdef'd out.
-- 
Steven Critchfield <critch at basesys.com>