[asterisk-dev] [Code Review] Eliminate redundant and possibly dangerous close/fclose pairs in chan_sip and tcptls.

[jrose]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1576/
-----------------------------------------------------------

(Updated Nov. 17, 2011, 11:01 a.m.)


Review request for Asterisk Developers, David Vossel and mjordan.


Changes
-------

Removes all attempts to directly close() file desciptors belonging to tcptls_session instances in chan_sip.c and tcptls.c, replacing them with ast_tcptls_close_session_file
Changes order of SSL_close operation.  Starts by attempting to SSL_shutdown (and executes it a second time if it doesn't receive peer confirmation per http://www.openssl.org/docs/ssl/SSL_shutdown.html as well as checks the FD to make sure the retrieval wasn't in error.  Also issues a log message if there is an error in close() containing relevant errno information.


Summary
-------

According to the reporter, chan_sip and tcptls were using an odd combination of close and fclose which can result in undefined behavior.  Following the man pages for fclose and close, attempting to fclose a file with an already closed file descriptor results in undefined behavior, and fclose itself will already close the file descriptor, so using fclose and then close is redundant.  The reporter suggested as well that since file descriptors will experience frequent reuse that using fclose and then close could also result in closing a file descriptor that is in use elsewhere since there is time for that that file descriptor index to be reclaimed in the file descriptor table during the window between that fclose and the following close operation... or at least that's how I interpreted it.

I removed all uses of the close function when there was an adjacent fclose.  I'm still not 100% sure if this is the right approach since this behavior introduced in a patch by dvossel in r225445, which can be seen here: http://lists.digium.com/pipermail/asterisk-commits/2009-October/038031.html  I'm a little worried that this might be because the file descriptor received a redundant reference somewhere along the line and these close() functions might have been used to close a file descriptor leak or something along those lines.


This addresses bug ASTERISK-18700.
    https://issues.asterisk.org/jira/browse/ASTERISK-18700


Diffs (updated)
-----

  /trunk/channels/chan_sip.c 344846 
  /trunk/include/asterisk/tcptls.h 344846 
  /trunk/main/tcptls.c 344846 

Diff: https://reviewboard.asterisk.org/r/1576/diff


Testing
-------

Set up some TLS calls and used core show fd (with DEBUG_FD_LEAKS enabled) to make sure this wasn't causing a bunch of file descriptor leaks.  From what I could find, it wasn't.


Thanks,

jrose

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20111117/1f12933b/attachment.htm>