[Asterisk-code-review] func_channel: Added new OTHER_CHANNEL function (asterisk[16])

[N A]

N A has posted comments on this change. ( https://gerrit.asterisk.org/c/asterisk/+/15908 )

Change subject: func_channel: Added new OTHER_CHANNEL function
......................................................................


Patch Set 1:

> Patch Set 1:
> 
> > Patch Set 1:
> > 
> > > Patch Set 1:
> > > 
> > > I need to give this thought as to whether this is something that is reasonable or not. It feels very very very dangerous to go down this kind of road and allow arbitrary access to other channels like this, including to their dialplan functions (I'm wondering if it's possible to cause a deadlock using this).
> > > 
> > > What are the thoughts from others?
> > 
> > Just to explain my thought process, my rationale was to explicitly allow for access to their dialplan functions. I have a scenario in my dialplan currently, where I would like to set a custom CDR variable on another channel (which can be perfectly legitimate). MASTER_CHANNEL doesn't help because I use Dial with the n option to prevent optimization, so the new channel is the master channel. I wrote this so I could do just that, and write into another channel's CDR variable. I'm aware that issues from irresponsible usage could arise if the dialplan writer doesn't have good discretion but currently there does not seem to be any other way to perform these operations.
> 
> I can understand that, but things can get extremely dangerous and people will use this in other ways. When that happens and it goes wrong, deadlocks, crashes, that reflects on the project and is something we then have to deal with. Users have an expectation that things should not allow themselves to shoot themselves in the foot easily. There are certainly cases where it can be done, but dialplan applications and functions are safe for the most part. This feels like it drifts too far into the wild west territory.

Thanks, that makes complete sense. Is there anything that could be changed about the way that it's currently written to prevent some of this dangerous stuff, like preventing "dangerous manipulations"? Or is it just kind of inherent to this type of function in a way that would be hard to limit, other than a warning "Don't use if you don't know what you're doing"?


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

Gerrit-Project: asterisk
Gerrit-Branch: 16
Gerrit-Change-Id: I7492645ae4307553d0f586d78e13a4f586231fdf
Gerrit-Change-Number: 15908
Gerrit-PatchSet: 1
Gerrit-Owner: N A <mail at interlinked.x10host.com>
Gerrit-Reviewer: Friendly Automation
Gerrit-CC: Joshua Colp <jcolp at sangoma.com>
Gerrit-Comment-Date: Mon, 17 May 2021 14:51:52 +0000
Gerrit-HasComments: No
Gerrit-Has-Labels: No
Gerrit-MessageType: comment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-code-review/attachments/20210517/73741cdb/attachment.html>