[asterisk-bugs] [Asterisk 0014276]: [patch] allow storage of vmsecret in users voicemail spool directory
Asterisk Bug Tracker
noreply at bugs.digium.com
Mon Jan 19 15:07:16 CST 2009
A NOTE has been added to this issue.
======================================================================
http://bugs.digium.com/view.php?id=14276
======================================================================
Reported By: klaus3000
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 14276
Category: Applications/app_voicemail/NewFeature
Reproducibility: have not tried
Severity: minor
Priority: normal
Status: new
Asterisk Version: SVN
Regression: No
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!): 169203
Request Review:
======================================================================
Date Submitted: 2009-01-19 09:33 CST
Last Modified: 2009-01-19 15:07 CST
======================================================================
Summary: [patch] allow storage of vmsecret in users voicemail
spool directory
Description:
When secretinspool=yes in voicemail.conf, voicemail reads and writes the
secret into a file in the users voicemail spool directory. For example if
voicemail is configured for user 1234 in voicemail context foobar, then the
secret will be stored in /var/spool/asterisk/voicemail/foobar/1234/secret.
When secretinspool=no, it uses the old behavior and stores secrets into
the configuration files.
Note: realtime voiceboxes are never influenced by this parameter
======================================================================
----------------------------------------------------------------------
(0098151) klaus3000 (reporter) - 2009-01-19 15:07
http://bugs.digium.com/view.php?id=14276#c98151
----------------------------------------------------------------------
The only problem I can see is if a user calls into voicemail two times
concurrently and changes the secret in both calls at the same time. But
even here I think the race is handled by the OS - one of them is always
faster and gets overwritten by the slower one, or in worst case the second
fopen/fprintf causes an error in which case the secret is not written to
file.
Issue History
Date Modified Username Field Change
======================================================================
2009-01-19 15:07 klaus3000 Note Added: 0098151
======================================================================
More information about the asterisk-bugs
mailing list