| Summary: | ASTERISK-25996: Remove "live_dangerously" requirement on DB(read) | ||||||
| Reporter: | Andrew Nagy (tm1000) | Labels: | |||||
| Date Opened: | 2016-05-04 15:51:43 | Date Closed: | 2016-08-04 14:24:18 | ||||
| Priority: | Minor | Regression? | |||||
| Status: | Closed/Complete | Components: | Core/General Core/SQLite3 | ||||
| Versions: | 11.21.2 13.8.2 | Frequency of Occurrence | |||||
| Related Issues: |
| ||||||
| Environment: | Attachments: | ||||||
| Description: | Please Remove the "live_dangerously" requirement on DB(read). This unintentionally breaks AMI commands like extensionState when calling dynamic hints based on DB values.
EG: {code} exten => _*992*3*X.,1,Hangup exten => _*992*3*X.,hint,${DB(restapps/hints/conference/${EXTEN:7})} {code} {code} freepbxdev1*CLI> database show restapps/hints/conference /restapps/hints/conference/1000 : confbridge:81000&confbridge:81001 {code} When I run extensionState over the AMI against "*992*3*1000" the DB read command is blocked because it's "dangerous" {code} dangerous DB read operation blocked {code} I don't think a DB read at a hint level should be blocked. Furthermore requiring "live_dangerously" to make this even work is even scarier (and something I don't want to entertain :-) ) Some history: {quote} 1:34 PM <tm1000> if a phone subscribes to said hint instead it works. 1:35 PM <tm1000> its just if I asked for the hint through extensionState first before the phone ever did the hint is effectively broken forever 1:35 PM <gtjoseph> so you're getting the “dangerous DB read operation blocked" when calling ExtensionState?? 1:36 PM <gtjoseph> maybe i need to test again with a pattern match. 1:36 PM <gtjoseph> because i get no attempt to even call the DB function 1:37 PM <@file> for pattern matches the act of requesting or subscribing will in and of itself create a specific hint and evaluate the passed variables/contents 1:37 PM <gtjoseph> yeah, i dimly remember that 1:40 PM <gtjoseph> ok, it works with DB(read) allowed in AMI. 1:41 PM <gtjoseph> tm1000: can you open a separate issue to remove the "live_dangerously" restriction on DB(read)? 1:45 PM <tm1000> gtjoseph: sure 1:45 PM <tm1000> anything you want me to put in the ticket specifically? 1:46 PM <gtjoseph> just the requirement. not sure how to do it securely. {quote} | ||||||
| Comments: | By: Asterisk Team (asteriskteam) 2016-05-04 15:51:44.106-0500 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. By: George Joseph (gjoseph) 2016-05-04 15:57:56.176-0500 I can reproduce this issue but the fix might not be so simple. The restriction on DB(read) is for any AMI call, probably to prevent the use of SetVar/GetVar. Unfortunately, the pbx_functions that implement this can't tell the difference between DB being called via GetVar/SetVar directly from AMI and DB being called from the dialplan because ExtensionState was called from AMI. The former can be construed as a security risk but the latter, should not. By: Andrew Nagy (tm1000) 2016-05-10 14:40:23.183-0500 Note: This also breaks DB hints when reload() is requested over AMI as it's the same thing "blocked DB reads" during AMI events. By: Richard Mudgett (rmudgett) 2016-07-27 17:45:51.727-0500 Using an AMI Getvar action with the {{EXTENSION_STATE}} function on the described extension will also trigger the blocked DB read. By: Andrew Nagy (tm1000) 2016-07-27 19:05:09.663-0500 Hey Richard, That's actually how I originally ran into the issue :-) Just letting you know :-) By: Richard Mudgett (rmudgett) 2016-07-28 15:17:48.815-0500 Patches up on gerrit. They work from my testing. Let me know if they also work for your situation. By: Richard Mudgett (rmudgett) 2016-08-04 14:24:11.900-0500 Patches have been merged so I'm closing the issue. | ||||||